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ABSTRACT : Eight  Artificial  Intelligence  programming  languages 
(SAIL,  LISP,  MICROPLANNER,  CONNIVER,  MLISP,  POP-2,  AL  and  QLISP) 
are  presented  and  surveyed,  with  examples  of  their  use  in  an 
automated  shop  environment.  Control  structures  are  compared,  and 
distinctive  features  of  each  language  are  highlighted.  A simple 
programming  task  is  used  to  illustrate  programs  in  SAIL,  LISP, 
MICROPLANNER  and  CONNIVER.  The  report  assumes  reader  knowledge 
of  programming  concepts,  but  not  necessarily  of  the  languages 
surveyed . 
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This  report  describes  sose  recently  developec  Artificial 
Intelligence  programming  languages  in  the  context  of  a computer-aided 
manuf a c turi ng  environment.  The  languages  surveyed  are  SAIL*  LISP* 
"ICROPLANNE R , CONNIVER,  MLISP,  POP-2*  AL,  and  iLISP.  These  lan^uaoti 
are  distinct  from  languages  previously  used  in  computer-aidtd 
manuf a c tu ri ng  environments  LLeslie72D  in  that  they  provide  capabilities 
for  the  development,  of  high-level  symbolic  planning  and  supervisory 
control  in  addition  to  the  simple  numerical  control  of  machine  tocla. 
The  paper  includes  (1)  surveys  and  comparisons  of  the  distinctive 
features  of  these  languages  as  they  might  be  used  in  a 
computer-automated  manufacturing  environment*  (2)  a sample  automatcc 
manufacturing  task*  and  how  it  might  be  expressed  as  a program  in  each 
language*  (3)  discussions  of  the  s tancard ita t ion  status  of  each 
language*  and  (4)  conclusions  with  emphasis  on  the  types  of  features 
which  are  most  desirable  ana  applicable  to  the  automated-shop 
env  i ronme  nt  • 
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2.1.  lQi£2fi«£iiflQ 

SAIL  has  Its  origins  in  a Merger  of  LEAP  Cfe  loman69i . an 
associative  language*  and  a version  of  ALGOL  60  LNaur60J.  Therefore* 
unlike  most  of  the  other  artificial  intelligence  languages*  it  is  not 
LISP-baseo.  Instead,  it  is  a general  purpose  compiled  language  with  on 
extensive  run-time  library  of  functions.  As  befits  its  ALGOL  origins* 
SAIL  has  block  structure  and  explicitly  typed*  statically  scopec 
variables.  The  uata  types  available  include  INTEGER,  REAL*  STRINGS  of 
arbitrary  length*  structure*  pointer*  LIST,  SET,  ITEM,  and  aggregates 
of  the  previous  ( i.e. « ARRAYs). 

Some  of  the  more  important  features  of  SAIL  a re  discussec 
separately  below.  These  include  the  associative  data  base  facility* 
the  capability  for  usage  of  SAIL  as  a host  language  in  a CODAStL 
CCODAS  YL71J  data  base  management  system*  the  control  structures*  an: 
the  system  building  facilities.  Finally*  a summary  is  presented  of 
current  s ta naa rdi zati un  efforts. 


2.2.  Associative  Data  base 

SAIL  contains  an  associative  data,  base  facility  known  as  LE*P 
which  is  used  for  symbolic  computations  This  enables  the  storage  and 
retrieval  of  informution  oased  on  partial  specification  of  the  data. 
Associative  data  is  stored  in  the  form  of  associations  which  are 
ordered  three-tuples  cf  ITEMs*  denoted  as  TRIPLES.  Examples  o*  TRIPLES 
a re : 

FASTEN  XOR  NAIL  EQV  HAMMER; 

FASTEN  XOR  SCREW  EQV  SCREWDRIVER; 

FASTEN  XOk  sOLT  ESV  PL2ER; 


Associations  may  be  conceptualizes  as  representing  a relation  of  the 
form 

Attrioute  XOR  Object  EQV  Value 
or  Attrioute  (Object)  = Value 


Most  programming  languages  (e.g.*  LISP)  provide  the  following 
associative-like  mechanism: 

Given:  A 1 1 ri ou t e * Ob j e c t 

Find:  Value 


However*  SAIL  enaoles  the  programmer  to  specify  any  of  the  components 
of  the  association*  and  then  have  the  LEAP  interpreter  search  the 
associative  store  for  all  triples  which  have  the  same  items  in  the 
specified  positions.  For  example*  the  following  may  be  useo  tc 
retrieve  «ll  items  that  can  fasten  a nail: 

FASTEN  XOR  NAIL 


An  ITEM  is  a constant  and  is  similar  to  a LISP  atom.  Items  have 
names  anc  may  also  be  typed  so  that  data  can  be  associated  with  them. 
An  item  may  be  declared*  or  created  during  execution  from  a storage 
pool  of  items  by  use  of  the  function  NEW.  For  example: 
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REAL  ITEM  VISE; 


declares  VISE  to  oe  an  item  which  may  have  a datum  of  type  reel 
associate a with  it*  The  datum  associated  with  an  item  is  obtainea  by 
use  of  the  function  DATUM.  Thus,  DATUM(VISE)  might  be  interpreted  as 
the  capacity  of  the  vise. 

In  order  to  deal  with  items,  the  user  has  the  capability  of 
storing  them  in  variables  (ITEMVARs).  SETs,  LlSTs,  and  associations. 
The  distinction  between  SETs  and  LlSTs  is  that  an  explicit  order  is 
associatec  with  the  latter,  whereas  there  is  no  explicit  order 
associateo  with  the  former.  In  addition,  an  item  may  occur  more  than 
once  in  a List. 

Associations  are  ordered  three-tuples  of  items  and  may  themselves 
be  considered  as  items  and  therefore  participate  in  other  associations. 
Triples  are  added  to  the  associative  store  by  use  of  a V*KE  statement 
and  erases  from  the  associative  store  by  use  of  an  ERASE  statement. 
For  example,  the  following  code  could  be  used  to  detach  assembly  1 from 
assembly  2.  and  attach  it  to  assemDly  3: 

ERASE  ATTACHED  XOR  ASSEMBlYI  EQV  ASSEMBLY?; 

MAKE  ATTACHED  XOR  ASSEMBLYI  EQV  ASSEMBLY2; 


The  motivation  for  using  an  associative  store  is  a flexible  search 
and  retrieval  mechanism.  Binding  Booleans  and  Foreach  statements  are 
t two  methods  of  accomplishing  these  goals. 

The  binding  Boolean  expression  searches  the  associative  store  for 
a specified  triple  and  returns  TRUE  if  the  triple  is  found  and  FALDL 
otherwise.  The  aim  of  the  search  is  to  find  an  association  which  meets 
the  constraints  imposed  by  the  specified  triple.  If  seme  of  the 
components  of  the  triple  are  unknown  (such  components  are  preceded  ty 
the  special  item  BIND),  then  a successful  search  will  result  in  the 
binding  of  the  designated  component.  For  example: 

IF  FASTEN  XOR  BIND  OBJECT  EQV  PLIER  THEN  PUT  OEJECT  IN  PL1EA ! SET ; 


In  this  case  the  store  is  searched  for  an  object  that  can  be  fasteneo 
by  a PLIER  and  if  such  an  object  is  found,  it  Vs  placed  in  tne  stt 
PLI ER ! SET . Note  the  use  of  the  item  variable  OBJECT  in  the 
association.  A successful  search  will  result  in  this  variable  being 
bound . 

The  FOREACH  statement  is  the  heart  of  LEAP.  It  is  similar  to  the 
FOR  statement  of  Au60L  in  that  the  body  of  the  statement  is  executed 
once  for  each  binding  of  the  control  variable.  For  example: 

FOREACH  X I PART  XOR  B747  EQV  X AND  DATUM  <X)  < 3 
DO  PUT  X IN  B747 !ORDER  !SET; 


In  this  case,  assuming  that  the  datum  associated  with  each  part  denotes 
quantity  at  hand,  the  associative  store  is  searched  for  all  parts  of  a 
. B747  of  which  there  are  less  than  three  on  hand.  These  parts  are 

placed  in  the  set  5747! ORDER !SET. 

I 


2.3.  M§naa£m£nt  Fasiiii* 


Unlixe  other  artificial  intelligence  languages,  SAIL  has  the 
capability  of  being  used  with  an  existing  data  base  management  system 
(DBMS-10  lDEC])  to  handle  large  data  bases  stored  on  external  storage. 
An  interface  exists  £Samet76J  which  allows  SAIL  to  be  used  as  the  oata 
manipulation  language  in  a CODASYL  based  data  base  management  system. 
SAIL  is  relatively  unique  in  this  respect  in  that  COBOL  CC060L743  has 
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almost  oeen  exclusively  used  as  the  data  manipulation  languaae  (DML)  of 
such  systems.  This  situation  is  not  surprising  since  examination  of 
the  data  description  facility  of  the  CCDASYL  report  reveals  a very 
stron,  similarity  to  the  data  division  of  COBOL.  Nevertheless,  there 
have  oeen  some  attempts  to  use  FORTRAN  (CStacey743,  CRAPIDATA3). 

Ideally,  a data  manipulation  language  should  include  the  followin9 
features.  First,  a full  procedure  capacility  which  allows  parameter 
passing,  aynamic  storage  allocation,  ano  recursion.  Second*  processing 
of  Boolean  requests  should  not  be  difficult.  In  a CCBOL-Daseo  system 
this  task  is  rather  cumbersome  as  pointed  out  by  CParsons74j.  In  order 
to  avoid  currency  problems  raised  by  partial  satisfaction  of  Boolean 
requests  (the  backtracking  problem  CTaylor763),  the  user  must  build 
collections  of  pointers  to  related  records.  Third,  there  should  be  a 
capability  for  Building  an  in-core  data  base  so  that  operations  such  as 
set  UNION  and  set  INTERSECTION  can  be  performed  without  the  overheao  of 
accessing  extended  storage  more  than  once  for  any  record. 

SAIL  has  a mechanism,  LEAP,  for  building  associative  oata  oases. 
Currently,  this  only  works  for  internal  memory  due  to  implementation 
decisions.  SAIL  also  has  a recora  structure  capability  which  enables 
the  user  to  builc  an  in-core  oata  base.  In  a COEOL-based  data  base 
management  system,  whenever  the  user  obtains  an  instance  of  a recoro 
type  from  the  data  base  li.e.,  he  locates  it  via  a FIND  ano  fetches  it 
via  a GET),  he  has  no  convenient  way  of  keeping  it  in  temporary  memory 
while  obtaining  another  instance  of  this  record  type.  Cf  course,  he 
can  allocate  temporary  storage  for  the  various  fields;  however,  this 
becomes  rather  unwieldy,  especially  when  he  wishes  to  keep  track  cf 
more  than  two  instances  of  a record  type.  Alternatively,  instances  cf 
certain  record  types  can  be  refetcned  from  the  data  base.  In  fact, 
this  is  the  strategy  that  is  generally  followed.  However,  the  cost  is 
orohibitive. 

oriefly,  the  SAIL  interface  provides  a SAIL  recora  structure 
declaration  for  e.ch  record  type  that  has  been  defined  in  the  data  Laue 
management  system.  Primitives  exist  for  the  creation  anj  modification 
of  such  records.  The  dynamic  storage  allocation  capability  of  SAIL 
enables  the  creation  of  several  instances  of  each  recede  type  each  of 
which  is  identified  by  an  entity  known  as  a recoro  pointer. 

As  an  example  of  the  use  of  oAIL  as  a host  'ngtage  i'  * data  base 
management  system,  consider  the  following  progr?«  fr  qn.ent  . The  task 
is  to  traverse  a set  named  SUPPLIER  owned  t ■>  a vAREHGUEI  record  and 
extract  an  integer  oata  item  known  as  PARTNUM  eacn  PACT  record 

which  is  a member  of  the  set.  The  exact  inst  t.  1 t h pat  occurrence 
is  identified  by  the  owner  record,  WARE  SE,  having  the  value 
ELECTRICAL  tor  the  data  item  INDUSTRY.  5 ~ct  SAIL  has  a data 
structuring  facility  (known  as  a RE C OR D ! C L Aa • .nq  similar  to  a FL/1 
Caeech703  structure)  we  define  a data  structure  mown  as  LIST*  ano  a 
function  to  add  items  to  the  front  of  a LISTX  structure.  The  cata 
structure  LISTX  has  two  fields  - ELEMENT  which  is  of  type  INTEGER  and 
NEXT  which  is  of  type  RECORDiPOINTER  (and  points  to  another  instance  of 
the  LISTX  data  structure).  The  function  ADDTOLIST  has  two  arguments  - 
a pointer  to  the  head  of  an  instance  of  LISTX  and  the  integer  to  ie 
added  to  this  instance. 

RECORD  ! CL  AS S Li STX ( INTE GER  ELEMENT; 

RECORD ! POINTER  (LISTX)  NEXT); 

PkOCEDURE  ADD TOLIST (RE FERtNCE  R E CO R D ! POI NT ER ( L I ST  X ) HEAD; 

INTEGER  VAL); 

BEGIN 

RE  COR D »P0 INTER  (LISTX)  TEMP; 

TEMP  :=  NEW  ’ELEMENT  (LI STX); 

LI STX  :ELEMENTCTEMP3  :=  VAL; 

LI STX  :NLX TCTEMP3  :=  HEAD; 

HEAD  :=  TEMP; 

END; 


The  C060L/DML  ana  SAIL  encodings  are  given  below. 


The  critical 
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difference  is  the  step  "Add  PARTNUM  in  PART  to  result  list."  It  is  not 
immediately  obvious  how  the  concept  of  a list  would  be  implemented  in 
COBOL. 


COBOL  Program: 

MOVE  "ELECTRIC AL"  TO  INDUSTRY  IN  WAREHOUSE. 
FIND  WAREHOUSE  RECORD. 

IF  SUPPLIER  SET  EMPTY  60  TO  NONE ! SUPPL IED . 
NEXT:  FIND  NEXT  PART  RECORD  OF  SUPPLIER  SET. 

IF  ERROR-STATUS  = 0307  SO  TO  ALL?FOUND. 

6 ET  PART. 

Aud  PARTNUM  in  PART  to  result  list* 

SO  TO  NEXT. 

AlL ! FOUND  : 


SAIL  Program: 

INDUSTRY  :=  "ELECTRICAL"; 

FINDfCALC (WAREHOUSE); 

IF  EMPTY ! SET (SUPPLI ER  ) 60  TO  NONE ! SUPPLI ED ; 
WHILE  TRUE  DO  BESIN 

FIND !NEXT( PART, SUPPLIER); 

IF  ERROR ! STATUS  = 0307  THEN  DONE; 

SET (PART); 

ADDTOLIST (HE AD, PARTNUM); 

EN  D ; 


2.4.  CsDlrfii  5i£U£lU££5 

In  audition  to  the  ususal  control  structures  associated  with 
ALSOL-like  languages  (e.a.,  FOR  loops,  WHILE  loops,  case  statements, 
recursive  procedures,  etc.),  SAIL  has  capabilities  to  enable  parallel 
processing,  backtracking,  and  coroutines.  In  SAIL,  a process  is  « 
procedure  that  may  oe  run  i ndepenoent ly  of  the  main  procedure.  Thus 
several  processes  may  ue  run  concurrently.  Note  that  the  main 
procedure  is  also  a process. 

A process  is  created  with  a SPROUT  statement  as  follows: 

SPROUT (<i tem>,<procedure  call>,<options>) 


where  <it*m>  names  the  process  for  future  reference,  <procedure  call> 
indicates  what  the  process  is  to  do,  and  <options>  is  used  to  specify 
attributes  of  the  SPROUTed  and  current  process.  Unless  otherwise 
stipulated  (in  <options>),  a SPROUTed  process  begins  to  run  as  soon  as 
it  is  SPROUTed  and  in  parallel  with  the  SPROUTing  process. 

Similarly,  there  exist  primitives  which  result  in  the  suspension 
of  a process,  the  resumption  of  a process,  and  in  the  blocking  of  a 
process  until  a number  of  other  processes  have  terminated.  These  tasks 
are  accomplished  c*y  the  SUSPEND,  RESUME,  and  JOIN  primitives 
respect  ively. 


SUSPEND  and  RESUME  have  as  their  arguments  single  items  while  JOIN 
has  a set  of  items  as  its  argument.  These  items  are  the  names  that 
have  been  set  up  tor  the  process  by  an  appropriate  SPROUT  command. 

For  example,  a procedure  to  tighten  a bolt  may  be  defined  as 
f ol lows  : 

ITEM  Pi ,P2; 


SPROUT (Pi ,6RASP(HANDl, SCREWDRIVER) ); 
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SPROUT ( P2 , GRASP <HAND2,BOLT)); 

J OIN<(  PI , P2>)  ; 

TURN(H AND  1 ,CLOCKWlSE); 


S i nc  t SAIL  runs  on  a single  processor  computer  system,  true 
multiprocessing  is  not  possible.  Instead,  the  SAIL  runtime  system 
contains  a scheduler  which  decides  which  process  is  to  run  and  for  hew 
long.  The  programmer  makes  use  of  the  <options>  field  of  the  SPROUT 
statement  to  specify  information  which  the  scheduler  uses  to  determine 
the  next  process  to  be  run.  Such  information  incl ude  s time  quantum 
sizes,  priority,  whether  or  not  to  immediately  run  the  SPROUTeo 
process,  etc. 

A process  may  re  suit  in  the  binding  of  I^EMVARs  by  use  of  c. 
HATCHING  PROCEDURE,  which  is  basically  a boolean  procedure.  When  one  of 
the  parameters  is  an  unbound  FOREACh  itemvar,  then  upon  success  the 
parameter  will  be  bound  • The  matching  procedure  is  actually  SPROUTtc 
as  a coroutine  process  and  SUCCEED  anc  FAIL  are  variants  of  RESUfE 
which  return  values  of  TRUE  or  FALSE  respectively.  In  addition,  FAIL 
causes  the  process  to  terminate  whereas  when  the  matching  procedure  is 
called  by  the  surrounding  FOREACH  via  backup,  then  the  procedure  is 
resumed  where  it  left  off  on  the  last  SUCCEED. 

For  example,  consider  a box  containing  a number  of  different 
fasteners  (nails,  regular  screws,  bolts,  nuts,  tacks,  etc.).  The  goal 
is  to  obtain  Phillips  screws.  This  can  be  achieved  by  the  following 
MaTCHI No  PROCEDURE  which  returns  a different  Phillips  screw  each  time 
it  is  invoked. 

MATCHING  PROCEDURE  GET ! F AS  TEN ER  (? ITEMVAR  F AS T ENE R , F ! T YPE > ; 

BEGIN 

FOREACH  FASTENER  I F Ah TEN  ER  IN  BOX  AND 

TYPE  XOR  FASTENER  E Q V F!TYPE 

DO  SUCCEED; 

FAIL; 


Note  that  FASTENER  is  a FOREACH  ITEMVAR  which  upon  success  will  be 
bound . 

backtracking  is  supported  by  variables  of  type  CONTEXT.  However, 
the  programmer  must  specify  the  points  to  which  backup  is  to  occur  (for 
example,  recall  SUCCEED).  State  saving  and  restoring  is  achieved  by 
use  of  CONTEXT  variables  which  act  as  pointers  to  storage  areas  of 
undefined  capacity  in  which  are  stored  the  entities  to  be  saved  and 
restored.  Actual  state  saving  ana  restoring  is  accomplisheo  by  use  of 
the  primitives  REMEMBER  and  RESTORE. 

Processes  ma * communicate  with  each  other  by  use  of  the  SAIL  event 
mechanism.  This  is  a message  processing  system  which  enables  the 
programmer  to  classify  the  messages  and  to  wait  for  certain  events  to 
occur.  Events  occur  via  the  CAUSE  construct  which  has  as  its  arguments 
the  event  type,  the  actual  notice,  and  instructions  with  respect  to  the 
disposition  of  the  event.  Similarly,  there  is  a construct  known  as 
INTERROGATE  which  specifies  a set  of  event  types  and  instructions  with 
respect  to  the  disposition  of  the  event  notice  associated  with  the 
designatec  event  types.  A variant  of  this  facility  has  been  usee 
extensively  in  the  implementation  of  the  Stanford  Hand  Eye  Project 
t Fe lama  n7 1 j . 


2»5.  s*stfilE  aaiiaiDa  £.aB4aHiiits 

SAIL  includes  many  features  which  are  designed  to  aid  in  system 
building.  Assembly  language  statements  may  oe  interspersed  with 
regular  SAIL  state me nts  by  use  of  the  STARTlCODE  and  QUICK* CODE 
constructs.  A n umbe  r of  different  files  which  are  to  be  used  with  the 
program  can  be  specified  via  use  of  REQUIRE  statements. 

The  statements: 

REQUIRE  "TOOLS"  LOAD !M0DULE; 

REQUIRE  "CAHL1BC1,33"  LIBRARY; 


will  cause  SAIL  to  inform  the  loader  that  the  file  TOOLS. REL  must  ce 
loaded.  In  addition,  the  file  CAMLIE  on  disk  area  Cl, 33  serves  as  a 
library  and  is  searched  for  needed  routines. 

The  state  men  t : 

REQUIRE  "HEADER. SA1"  SOURCEJFILE; 


will  cause  the  compiler  to  save  the  state  of  the  current  input  file, 
and  scan  HEADER. SAI  for  program  text.  khen  HEADER.  SAI  is  exhausted, 
scanning  of  the  original  file  resumes  at  a point  immediately  following 
the  REQUIRE  statement.  This  feature  is  particularly  useful  when 
dealing  with  libraries  since  in  this  case  the  REQUIREd  file  can  contain 
EXTERNAL  Declarations  thereby  freeing  the  application  programmer  from 
such  work  and  possiole  errors. 

A rather  extensive  conditional  compilation  capability  is 
associated  with  SAIL.  This  enables  the  development  of  large  programs 
which  can  be  parameterized  to  suit  a particular  application  without 
compiling  unnecessary  code  and  thereby  wasting  memory  for  program 
segments  which  art  never  used.  This  capability  is  used  to  enahance  a 
macro  facility  to  include  compile-time  type  determination;  for  loops, 
while  statements,  and  case  statements  at  c omp i l e - t i me ; generation  of 
unique  symbols,  ano  recursive  macros.  For  example: 

DEFINE  GRASP(SIZE)  = ClFCR  SIZE  > 1 THENC  VISE 

ELSEC  PLIERS 
ENDC3; 


results  in  the  definition  of  a macro  named  GRASP  having  one  formal 
parameter,  SIZE.  The  result  is  the  name  of  a tool  that  is  appropriate 
for  the  size  of  the  item  that  is  to  be  grasped  - i.e.,  a vise  in  case 
size  is  greater  t h an  1 (assuming  size  is  measured  in  centimeters,  etc.) 
and  pliers  otherwise.  For  example: 

T COL  1 :=  oRASPCIO.O); 

TO0L2  :=  GRASP ( 0.5 ) ; 


will  result  in  the  following  statements: 

TC0L1  :=  VISE; 

T00L2  :=  PLIERS; 


Note  that  the  choice  is  made  at  compile-time  and  thus  the  programmer 
need  not  be  concerned  with  the  available  grasping  mechanisms  Thus  the 
program  compilation  step  can  be  used  to  aid  in  the  writing  of  the 
program.  The  example  illustrates  the  importance  of  such  a feature  when 
certain  tasks  can  be  achieved  by  similar,  yet  not  identical,  means. 

SAIL  also  provides  an  excellent  interface  with  the  operating 
system.  This  enables  its  use  for  real-time  applications  such  as 
control  of  external  devices.  In  fact,  interrupts  can  be  handled  ano 
the  user  has  at  his  disposal  all  of  the  I/O  capabilities  that  an 
assembly  language  programmer  has.  This  enables  the  development  of 


7 


iwwiS  ^ . • — 


■ - — 


programs  ranging  from  scanners  to  mechanical  arm  controllers*  In 
addition  to  compatibility  with  assembly  language  debuggers*  SAIL  has  a 
high-level  breakpoint  package  known  as  bAIL  CReiser75j. 


2.6.  S ta  nda  rd  ija  iifiD 

Currently*  SaIL  nas  only  been  implemented  on  the  PDP-10.  It  runs 
under  both  the  TENEX  CbBNEXECD  ana  T0pS-1G  CT0PS103  operating  systems. 
There  is  .n  effort  underway  at  SUMEX  to  develop  a language  similar  to 
SAIL  known  as  MAINSAIL  Cwilcox76D.  The  goal  of  that  project  is  to 
capture  the  features  that  make  SAIL  an  attractive  language  (in 
particular  the  ease  of  interaction  with  the  operating  system)  ana  to 
develop  a language  that  is  capable  of  being  run  on  a large  number  of 
machines.  The  orientation  of  the  project  is  towards  mini-computers. 
The  language  is  consicerably  different  than  SAIl  and  existing  SAIL 
programs  will  have  to  be  modified  in  order  to  be  capable  of  compiling 
An  extensive  run  time  library  is  being  provided  as  is  a reegrd 
structuring  facility.  It  is  still  uncertain  whether  the  associative 
data  base  capability  of  SAIL  (i.e.*  LEAP)  will  be  incorporated  in 
MAINSAIL. 


3*  It'S.  USE  £ami  ly  of  k£QflU£fl£S 


3.1.  LI$P 

LISP  (CMcCarthybOD,  CLevin65j,  CWeissman673,  Csiklossy763),  .list 
processing  language  developed  by  John  McCarthy  at  MIT  in  the  late  5C  * , 
is  an  implementation  of  parts  of  Alonzo  Church's  work  CChurchAlD  in  the 
lambda  calculus.  McCarthy  s intention  was  to  recast  the  elegance  of 
recursive  function  theory  as  a theory  of  computation.  Thus*  the  first 
implementations  of  LISP  relied  exclusively  upon  recursion  as  the 
computational  paraoi*m  (i.e.*  no  iteration)*  which*  although  elegant, 
resulted  in  a first  version  of  LISP  which  was  not  competitive  with 
FORTRAN  as  a practical  programming  tool.  However,  LISP's  character  has 
changed  considerably*  so  that  today  LISP  is  an  extremely  powerful  ar.o 
general  purpose  prowramming  language  which  nevertheless  retains  its 
origina  l elegance  . 

The  most  interesting  features  of  LISP  ore: 

(1)  The  language  is  practically  devoid  of  syntax;  all 
constructions  in  LISP  fall  into  two  categories:  atoms  and 
compositions  of  atoms. 

(Z)  Program  ana  data  are  interchangeable*  since  they  are 
represented  in  the  same  format,  therefore,  in  LISP  it  is 
possible  for  one  function  to  construct  another  function  as 
data,  then  execute  it  by  indicating  to  the  LISP  system  to 
regard  it  as  code;  alternatively*  an  existing  function  s 
code  may  be  examined,  modified  or  augmented  by  another 
function  at  run-time.  In  fact,  a function  is  capable  of 
s e l f -m odi f ica t i on  if  appropriate  care  is  exercized. 

(3)  Memory  allocation  ana  management  are.  automatic  and 
transparent  to  the  user,  except  where  the  user  explicitly 
desires  to  influence  them.  Ixith  the  exception  of  arrays* 
there  are  no  space  declarations  to  be  made,  freeinc  the 
programmer  from  the  details  of  space  allocation,  ana 

§enera l ly  allowing  for  the  unlimited  growth  of  any  given 
ata  structure.  (For  the  most  part,  LISP  data  structures 
have  no  size  or  complexity  constraints.)  Used  memory  which 
is  no  longer  involved  in  the  computation  is  recycled 
automatically  by  a garbage  collector  either  on  demand  from 
the  user  at  specified  points  or  automatically. 

(A)  LISP  is  an  interpreted  language.  The  system  proper  is  a 
function  of  one  argument,  (EVAL  X),  such  that  calling  EVAL 
with  any  LISP  data  structure  as  its  argument  causes  that 
argument  to  be  regarded  as  cooe  and  executed.  However,  most 
LISP  systems  include  a compiler  which  will  produce 

stand-alone  machine  code  for  interpreted  functions. 
Typically,  compilation  provides  an  order  of  magnitude 
speedup  which  makes  LISP  competitive  with  other  compiled 
languages,  or  even  with  well-coded  assembly  language.  Since 
interpreted  and  compiled  code  may  be  intermixed,  it  is 
possible  to  retain  the  flexibility  and  power  of  the 
interpreter,  while  obtaining  the  speed  reduired  for 
production  applications. 

(3)  LISP  remains  recursive,  while  also  accommodating  iterative 
algorithms  via  a so-called  PROG  feature,  both  recursion  and 
iterative  programming  are  illustrated  in  subsequent 

sections. 

(6)  Because  of  the  technique  LISP  uses  in  storing  local  and 

global  variables,  some  very  powerful  con  text -swi t ch i ng  can 
e carried  out,  providing  a fast  way  to  enter  and  exit 
hypothetical  planning  environments  and  to  cause  the 
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behavior  of  a program  to  vary  as  a function  of  its 
environmental  context* 


3.1.1.  Sl£U£lU££ 

LlSP's  Oata  structure,  called  the  S-exp r es s i on , is  simple,  yet 
extraordinarily  flexible,  providing  a substrate  upon  which  a programmer 
may  aesign  his  own  complex  data  structures.  An  S-exp res s ion  is  either 
an  "atom"  or  a "CONS  node".  An  atom  can  be  regarded  as  eitner  a 
variable,  a constant  (a  passive  symbol),  or  both.  There  are  no 
declarations  in  LISP;  new  atoms  are  simply  admitted  to  the  system  <.s 
they  are  scanneo  at  the  input  level,  and  atoms  with  the  same  name  are 
guaranteeo  by  the  system  to  be  unique  (i.e.,  they  have  the  same 
internal  pointer,  or  address). 

The  other  type  of  S-e xpre s s i on.  the  CONS  node,  provides  a means  of 
structuring  atoms  and  other  CONS  nodes  into  hierarchical  data 
structures.  A CONS  node  is  ordinarily  implemented  as  a single  computer 
word  (say,  36  bits  long)  which  contains  a left  pointer,  calleo  its  CAR, 
and  a riant  pointer,  called  its  CDR.  CONS  nodes  are  created  dynamically 
via  the  function  ICON*  X Y),  where  X ano  Y are  any  other  S -e xp r ess i cns , 
or  passively  (as  oata  constants)  via  the  construction  (X.Y).  CONS  nodes 
can  be  composed  to  form  arbitrarily  complex  hierarchies,  the  bottommost 
elements  of  which  are  usually  atoms  (i.e.,  pointers  to  atomic 
S-express ions) • 

To  illustrate,  suppose  we  wish  to  represent  a particular  tool,  So> 
a screwdriver,  in  a LISP  data  structure,  we  first  decide  upon  a name 
for  it,  say,  SC REwD HI VER-1 , and  what  characteristics  of  it  we  wish  to 
encode.  Let  us  suppose  the  characteristics  are:  type  is  Phillips,  coLr 
is  yellow,  shaft  length  is  10  centimeters,  and  head  size  is  C.2 
centimeter.  There  are  many  ways  to  encode  this  in  LISP;  the  externol 
representation  of  the  one  we  adopt  here  is: 


((NAME  SCREWDRI VER-1 ) 

(TOOL-TYPE  SCREWDRIVER)  1 

(STYLE  PHILLIPS) 

(SHAFT-LENGTH  10  CM) 

(COLOR-CODING  YELLOW) 

(HEAD-SIZE  0.2  CM)) 


Here,  all  symbols  such  as  NAME,  YELLOW,  etc.  are  LISP  atoms.  (So  too 
are  the  numDers;  however  numbers  are  not  entirely  equivalent  with 
symbolic  atoms.)  The  particular  hierarchy  we  have  adopted  is  a list  of 
lists,  where  each  sub-list  consists  of  an  initial  atom  describing  that 
sub -list's  role  in  the  structure,  and  a list  of  the  information 
associated  with  that  role  in  the  description. 

This  structure  would  be  graphically  represented  as  follows: 


1*1*1- 
♦ + 


--> I*  I*  I- 

♦ 4 


>1*1*1 


->  I * I * I 


♦  4 4 4 4 -♦  ♦ ♦ ♦ - ♦ ♦ 4 

l*l*|->l*|/|  l*l*l«>l*|/l  l*l*l»>l*|/| 

♦ ---4  4 — 4 4»  — 4 4— ♦ ♦ ♦ 4 — -4 


TOOL-TYPE 


-> I*  I*  I - 

4—4 


•>l*l/l 

4 4 


4 4 4 4 

1*1*1  — > 1*1/1 
4---4  4---4 


STYLE  PHILLIPS 


COLOR-CODING 


SCREWDRIVER-1  SCREWDRIVER 


YELLOW 


4 ♦ 4 — 4 4 — -♦  4-  — 4 4 4 ♦ 

|*|*|->|*|*|->|*|/|  |*  |*  |->  |*|*  | ->|*|/  | 

4 4 4 — -♦  4 — -4  4-  — ♦ 4~ -♦  4 — -♦ 

SHAFT-LENGTH  it)  CM  | ^3  !m 

HEAD-SIZE 


and  could  be  constructed  passively  (as  a fully  constant  structure)  via 
a quoted  S-exD res sion : 

'((NAME  SC  RE  WDR I VER-1 ) (TOOL-TYPE  SCREWDRIVER)  ...) 
or  dynamically  via  CONS: 

(CONS  (CONS  'NAME  (CONS  '$  C REWDR  1 VE  R-1  NIL)) 

(CONS  'TOOL-TYPE  (CONS  'SCREWDRIVER  NIL)) 

(CONS  'HEAD-SIZE  (CONS  0.1  (CONS  'CM  NIL))) 

) 

Since  it  would  be  a rather  harrowing  experience  to  construct  very  large 
S-expressions  dynamically  In  this  fashion*  LISP  provides  a spectrum  of 
higher-level  functions  for  constructing*  modifying  ano  accessing 
S-expressions.  Some  highlights  of  these  will  be  covered  briefly  in  a 
subsequent  section.  For  our  example*  a more  concise  expression  of  code 
which  would  build  this  structure  Dynamically  uoulo  be: 

(LIST  (LIST  'NAF.  : 'S  CREWDR  I VER-1  ) 

(LIST  'TOOL-TYPE  'SCREWDRIVER) 

(LIST  'HEAD-SIZE  0.3  'CM) 


Presumably*  having  defined  this  tool,  we  would  want  to  record  it 
as  one  available  tool  in  a large  supply  of  tools.'  Again*  there  would  be 
numerous  methods  of  doing  this.  One  way  would  simply  be  to  maintain  a 

§lobal  list  of  all  known  tools  In  the  system*  and  to  add  this  entire 
escriptlon  as  a new  tool  on  this  list: 


(SETQ  NEW-TOOL  '((NAME  SCREWDRIVER-1)  (TOOL-TYPE  SCREWDRIVER)  ...)) 
(SETQ  MASTER-TOOL -LIST  (CONS  NEW-TOOL  MASTER-TOOL-LIST)) 

(SETQ  Is  one  of  LISP'S  assignment  statements.)  Alternatively*  we  might 
wish  to  put  only  the  name  of  the  screwdriver  on  the  master  tool  list* 
and  associate  all  the  remaining  Information  with  property  DESCRIPTION 
on  SCREWDRIVER-1  s kCBBtCtZ  llil: 


i 


II 


■ I, , l„. 


(PUT  'SCREwDRIVER-1  'DESCRIPTION 

'•((  TOOL -TYPE  SCREWDRIVER)  ...  (HEAD-SIZE  C.Z  CP))) 

(SETQ  MASTfcR -TOOL -LIST  (CONS  ' S CR  E WDR  I V E R -1  M AST  E R- TOOL  -L  I S T ) ) 


3.1.2.  Prggerty  gists 

Any  LISP  atom  may  have  a property  list  (Duilt  up  from  CONS  nodes). 
Conceptually,  the  property  list  allows  the  attachment  of  an  arbitrary 
number  of  at t r i bute -va lue  pairs  to  the  atom,  thereby  serving  to 
describe  the  characteristics  of  the  real-world  entity  represented  by 
the  atom.  This  is  a powerful  feature  for  any  programming  language, 
since  it  allows  " mi c r o-des c r i p t i on sM  of  atoms  which  ordinorily  will  net 
be  seen  by  the  processes  that  manipulate  the  hierarchical  structures  in 
which  the  atom  participates.  These  m i cr ode s cr i pt i ons  can  be  maintained 
and  accessed  by  the  functions  PUT.  GET  and  REKPRGP  in  case  more  aetail 
about  an  atom  is  oesired. 

Properties  are  attached  to  an  atom  via  the  function  (PUT  <atcir.> 
<attribute>  <value>)»  looked  up  via  (GET  <atom>  <at t ri bute>) , an- 
removed  via  (REMPROP  <atom>  <a t t r i but e> ) • we  have  seen  one  way  to 
a ss oc i a te  -t he  screwuriver  information  wjth  the  atom  SCREWDRIVER-1  using 
property  lists.  Another,  more  convenient  way  would  be  to  split  apart 
all  the  various  attributes  of  this  atom,  making  each  a different  entry 
on  the  property  list: 


(PUT  'SCREWDRIVER-1  'TOOL-TYPE  'SCREWDRIVER) 
(PUT  'SCREWDRIVER-1  'STYLE  'PHILLIPS) 

(PuT  'SCREWDRIVER-1  'HEAD-SIZE  '(C.3  CM)) 


To  determine  SCR fcWDRIVER-1 's  heao  size,  we  would  then  write:  (CLT 
'SCREWDkI VER-1  'HEAD-SIZc).  If  such  an  attribute  of  SC REWDRI VE R-1 
exists,  it  will  be  located  and  returned. 


3.1.3.  E£E££5 £Oi£t ive  LI£P  £gt§  S t rugjy r£  lan iBy lading  FuntlifiOi 

we  include  here  a definition  and  brief  example  of  several  of  the 
more  stanaardt  high-level  LISP  functions  that  pertain  to  data  structure 
creation,  modification  and  searching. 


3 .1  .3. 1 . <H£3BfeR  X Y) 

If  S-expression  X is  a member  of  S-expression  Y (assumed 
list),  return  "TRUE",  otherwise,  return  "FALSE". 

EXAMPLE:  (MEMBER  'S CR EW DRI V E R - 1 M A ST E R-T 00 L-L I ST ) returns  a pointer  to 


to  be 


the  atom  T ("true")  if 
hA STE R-T 00L-LI ST,  and  a pointer 
otherwise. 


SCREWDR 1 VER-1 
to  the  atom 


is 

NIL 


on  the 
("false") 
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*•1.3 .2.  iASSSt  £ 12 

Y is  i list  of  lists.  Y is  scanned*  comparing  the  first  item  of 
each  sublist  to  X until  a match  is  found*  or  until  Y is  exhausted.  In 
case  a match  is  founo*  ASSOC  returns  the  entire  sublist  whose  first 
item  matched  X. 

EXAMPLE:  (ASSOC  'HEAD-SIZE  '((NAME  SCRE WDR I VER-1 ) ...  (HEAD-SIZE  C.3 
CM)))  woulc  return  the  sublist  (HEAD-SIZE  0.3  CM). 


3.1 .3.3.  (SUaST  X Y Z) 

x*  Y and  Z are  arbitrary  S-express ions.  SU6ST  creates  a new  copy 
of  Z*  where  all  occurrences  of  Y in  Z are  replaced  with  X s. 

EXAMPLE:  (SUeST  0.2  0.3  '((NAME  SCREW DRI VtR-1 ) ...  (hEAD-SIZc  C,Z 

CM)))  would  produce  a new  structure  for  our  screwdriver* 
identical  in  all  respects  to  the  original*  except  that  its 
head  width  would  be  0.2  instead  of  0.3. 


3. 1.3. 4.  (£EEEM&  £ 12 

X anc  Y are  lists.  A new  list  is  created  which  is  the  result  of 
appending  Y onto  the  end  of  X. 

EXAMPLE:  (APPEND  '((NAME  SCREWDRIVER-1)  (STYLE  PHILLIPS))  '((COLOR-CODE 
YELLOW)  (HEAD-SIZE  0.3  CM)))  would  produce  ((NAME 

SCREWDRIVER-1)  (STYLE  PHILLIPS)  (COLOR-CODE  YELLOW)  (HEAD-SIZE 
(i. 3 CM)) 


3.1.4.  LISP  I*i££ 

In  addition  to  atoms  and  CONS  nodes*  most  LISP  systems  include  the 
following  other  data  types: 


1.  integer  numbers 

2.  real  numbers 

3.  string  s 

4.  arrays 

5.  octal  numbers  (for  bit-level  manipulations) 


Some  versions  of  LISP  (notably  MACLISP  CMoon743)  have  highly  developed 
numerical  and  trigonometric  facilities  and  accompanying  optimizing 
compilers  geared  to  the  efficient  generation  of  "number  crunching 
software. 


3.1.5.  LISE  EUQtiifcQS 

A LISP  "program"  is  a collection  of  functions.  No  function  is 
syntactically  declared  as  the  "main  program".  Functions  are  generally 
typeless  (i.e.»  no  distinction  such  as  "integer"*  "real"*  "string", 
etc.  is  made).  However*  each  function  may  be  declared  so  that  its 
calling  arguments  are  passed  to  it  either  evaluated  (as  in  most 
programming  languages)*  or  unevaluated.  Except  for  this  distinction* 
there  is  no  need  for  function-related  declarations. 
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A function  is  regarded  as  simply  another  type  of  data.  As  such* 
one  typically  defines  a function  by  assigning  to  some  atom  the  function 
as  the  atom  s value.  Strictly  speaking,  the  function  itself  is 
nameless,  and  is  identified  by  the  form: 


(LAMBDA  <argument-list>  <body>> 


When  c "lambda  expression"  is  stored  as  the  value  of  an  atom.  we  say 
that  a function  has  oeen  defined.  Although  the  implementation  details 
governing  how  a lambda  expression  comes  to  be  associatea  with  an  atom 
vary  considerably.  one  common  format  for  defining  a function  in  LISP 
i s : 


(DtFUN  <name>  <arguments>  <body>) 


DEFUn  is  o macro  which  creates  the  appropriate  lambda  expression  ana 
assigns  it  to  the  atom  <name>  as  the  function's  body.  A function  may  be 
annihilated  or  alterea  simply  by  reassigning  the  value  of  the  atom 
which  represents  it.  Another  virtue  of  this  separability  of  a function 
from  its  name  is  that  nameless  functions  can  be  created  and  passed  *s 
arguments  to  other  functions  without  having  to  oother  to  name  them  if 
they  are  needed  only  once. 

To  illustrate  LISP  functions,  let  us  define  a function  of  t»o 
arguments.  (LOCATE-AlL  <tool-type>  < too l- l i s t >) » which,  given  the  name 
of  a tool  type  (e.a.,  SCREWDRIVER),  and  a master  tool  list,  will  search 
the  tool  list  for  tools  of  the  specified  ty^e  and  report  back  a list  of 
all  tools  of  that  type  it  finds.  Framing  this  as  a recursive  function, 
we  write: 


(DEFUN  LOCATE-ALL  (TYPE  MASTER-LIST) 

(COND  ((NULL  MASTER-LIST)  NIL) 

((EQUAL  (GET  (CAR  MASTER-LIST)  'TOOL-TYPE)  TYPE) 
(CONS  (CAR  MASTER-LIST) 

(LOCATE-ALL  TYPE  (C  DR  M AS T ER -L I S T ) ) ) ) 

(T  (lOCATE-ALL  TYPE  (CDR  M A ST  E R -L I S T ) ) ).)  ) 


that  is.  if  (COND)  the  master  list  is  (or  has  been  reduced  to)  NIL. 
then  report  back  "nothing";  otherwise,  if  the  next  item  on  the  master 
list  (i^s  CAR)  is  of  the  correct  type  (as  determined  by  the  GET).  then 
add  this  tool  to  the  list  to  be  reported  (i.e..  CONS  it  onto  the  frcnt 
of  this  list)  and  proceed  with  the  search  on  the  remainder  of  the  list 
(its  CDR);  otherwise  (T...).  simply  proceed,  without  recording  the 
current  tool. 

Alternatively,  we  could  express  this  algorithm  in  iterative  form 
via  the  Pk06  feature: 


(DEFUN  LOCATE-ALL  (TYPE  MASTER-LIST) 

(PROG  (RESULT) 

LOOP  (COND  ((NULL  MASTER-LIST)  (RETURN  RESULT)) 

((EQUAL  (GET  (CAR  MASTER-LIST)  ^TOOL-TYPE)  TYPE) 
( SETQ  RESULT  (CONS  (CAR  MASTER-LIST)  RESULT)))) 
(SETw  MASTER-LIST  (CDR  M A ST E R -L I S T ) ) 

(GO  LOOP))) 


i.e..  enter  a PROG  (akin  to  an  ALGOL  begin-end  block).  defining  one 
temporary  local  variable.  RESULT;  then,  while  the  master-list  remains 
non-nil,  repeatedly  examine  its  next  item,  collecting  those  with  the 
correct  type  on  the  RESULT  list  (via  SETQ,  LISP's  "assignment 
statement"),  scanning  to  the  next  tool  on  the  master  list  (SETQ 
MASTER-LIST  (CDR  MA  ST  E R -LI  S T ) ) . 
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3.1.6.  The  PR 0 G f eat £ 

As  just  illustrated.  LISP  ac commodates  i t e ra t i ve ly-ph ra st a 
algorithms  via  a construction  called  a "PROG".  A PROG  has  the  form: 


(PROG  < loc a l- va ri ab les>  <s t a t emen t-1 > ...  <s t atement-n>) 


As  a PROG  is  entereu,  the  local  variables  (if  any)  are  allocated  for 
the  scope  of  the  PROG,  and  each  is  initialized  to  NIL.  Next*  the 
statements  which  comprise  the  PROG's  body  are  sequentially  executeo 
(evaluateo)  until  execution  either  "falls  off  the  bottom"  of  the  PROG 

(an  implicit  exit  from  the  PROG),  or  until  a GO  or  RETURN  is 

encountered.  Statements  which  are  atoms  are  interpreted  as  labels 
within  a PROG,  ana  are  ignored  during  sequential  execution.  When  a GO 
is  encountered,  a branch  to  the  specified  laDel  occurs,  and  sequential 
execution  proceeds  from  that  point. 

Since  a PROG  introduces  some  temporary  variables  which  must  te 
reclaimed  as  the  PROG  is  exited,  there  must  be  some  way  of  informing 
LISP  that  a PROG  is  aoout  to  be  exited.  The  function  RETURN  is  used  for 
this  purpose,  informing  the  system  that  a PROG  is  being  exited,  and 
specifying  what  value  the  PROG  is  to  return  to  the  calling  environment. 

PROG's  may  be  nested  and  may  appear  at  any  point  in  a LISP 

program.  The  PROG  construction  will  typically  result  in  a more 

efficient  imp lementa t i on  of  an  algorithm  than  the  corresponoina 
recursive  implementation.  Although  some  feel  that  PROG  makes  LISP 
"impure",  it  is  in  reality  the  feature  which  is  probably  most 
responsible  for  LISP  s present  widespread  acceptance  in  both  the  A1 
community  and  elsewhere. 


3.1  .7.  LISE  aittaa 

Most  LISP  implementations  support  two  types  of  macros: 
compile-time  macros  and  scanner  macros.  A compile-time  macro  is  nothing 
more  than  a function  which,  when  evaluated.  computes  not  a final 
result,  but  another  S-expression  which,  when  evaluated,  will  compute  a 
final  result.  Thus,  when  a macro  is  encountered  by  the  LISP 
interpreter,  a dsyfele  evaluation  is  performed  (the  first  to  compute  the 
intermediate  form,  the  second  to  run  the  intermediate  form).  When  LISP 
functions  are  compiled  into  actual  machine  code,  the  compiler 
recognizes  macros  and  evaluates  them  once  to  obtain  the  intermediate 
form  which  it  then  compiles.  This  technique  is  a very  general  and 
powerful  implementation  of  the  macro  concept. 

Most  LISP  scanners  are  quite  modular,  in  the  sense  that  they  can 
be  conditioned  to  initiate  an  arbitrary  computation  upon  encountering  a 
given  character  in  the  input  stream.  Fcr  example,  in  Wisconsin  LISP 
LNorman693|  there  exists  a facility  called  (READ*AC  <char>  <function>), 
which  conuitions  the  scanner  to  call  <function>  (no  arguments)  whenever 
<char>  is  detecteo  in  the  input  stream.  <function>  is  tree  to  perform 
any  computation,  and  whatever  <function>  returns  is  spliced  into  the 
scanner's  input  stream.  This  style  of  table-driven  scanner  makes  it 
possible  to  superimpose  additional  syntax  on  LISP  input,  even  to  the 
point  where  LISP  can  model  another  language's  syntax  (by  redefining 
delimiters,  etc.).  MLISP  CSmith?03  is  an  example  of  this. 


3.1.8.  ¥sri£&i£  S£2E ing 

LISP  variable  values  are  derived  as  a function  of  the  run-time 
environment  rather  than  as  a function  of  lexical  environment.  As  a 
program  executes,  there  are  two  times  at  which  new  variables  are 
introduced,  or  "bound":  (1)  at  function  entry  time  (these  are  the  names 
of  the  function  s arguments  that  are  mentioned  in  the  LAMBDA 


expression),  and  (2)  at  PROG  entry  t i me  (i.e.,  the  PROG  s temporary 
variables).  Variables  are  “unbound"  at  the  corresponding  exit  times: 
when  a function  returns  or  when  a PROG  is  exitea. 

At  the  "top-level",  of  LISP  (when  no  function  is  currently 
executing),  any  variables  which  receive  values  are  thought  of  «s 
"global"  to  the  system.  Therefore,  at  any  given  moment  during 
execution,  there  will  be  a pool  of  global  atoms  plus  all  the  atoms 
introduced  via  LAMBDA  or  PROG  on  the  current  sequence  of  function 
calls.  All  these  variables  and  their  associated  values  ("bindings")  are 
recordeo  on  a structure  calleo  the  "association  list"  (A-LIST),  a 
user-accessible  list  of  CONS  nodes.  All  variable  lookups  consult  this 
list,  from  most  recent  to  least  recent.  Since  this  list  is  dynamically 
maintained  at  run-time,  the  question  of  what  variables  are  and  are  not 
bound  (i.e. | are  on  the  A-LIST)  is  exclusively  determined  oy  the 
dynamic  calling  environment,  rather  than  the  lexical  scope  of  variables 
at  the  time  functions  were  defined*  This  means  that  "free"  variables 
(ones  which  have  no  binding  at  the  current  level)  will  assume  a value 
at  run-time  which  is  dependent  upon  their  definitions  in  functions 
farther  up  the  calling  hierarchy.  In  this  manner,  one  function  "peeks 
into",  or  borrows  the  variables  of  another. 

c*y  changing  the  system's  A-LIST  pointer  while  inside  a function, 
that  function's  entire  environment  can  be  altered.  For  this  reason, 
LISP  is  a very  powerful  tool  wherever  hypothetical  reasoning  (involving 
switches  to  altered  contexts)  is  necessary.  Most  other  languages  either 
lack  such  an  ability,  or  make  it  difficult  to  carry  out.  In  LISF, 
context  switching  and  "taking  snapshots"  of  contexts  to  which  execution 
is  to  be  returned  are  very  natural  operations. 


3.1.9.  LISP  I/O 

Traditionally,  input/output  has  been  LISP's  weakest  link.  Most 
systems  define  at  least  the  following  I/O-related  functions: 


(READ)  read  an  S-expression 
(READCH)  read  an  individual  character 

(PRINT  X)  print  S-expression  X,  skipping  to  a new  line 
(PRINl  X)  print  S-expression  X on  the  current  output  line 
(TERPRI)  skip  to  beginning  of  new  line  on  output 


While  these  functions  provide  adequate  formatting  control,  most  LISFs 
are  deficient  in  f i l e-h and 1 1 no  operations.  (INTERLISP  CTe ite lman743  is 
the  exception,  with  more  highly  developed  interfaces  to  the  TENix 
virtual  operating  system).  We  regard  this  deficiency  as  more  of  a 
historical  accident  than  as  an  Inherent  problem  of  LISP  (since  adding 
these  features  is  simply  a matter  of  writing  the  code).  In  fact,  there 
are  efforts  underway  for  improved  multiple-file  interaction  and  random 
access  facilities  both  at  MIT  (MACLISP)  ana  at  Marylana  (Wisconsin 
LISP)  . 


3.1.10.  Gatbaae  £cllSLii&Q 

Since  LISP  data  structures  can  grow  in  unrestricted  ways,  a 
crucial  part  of  any  LISP  system  is  a conceptually  asynchronous  process 
called  the  "garbage  collector”.  The  role  of  this  process  is 
periodically  to  take  control,  mark  parts  of  storage  that  are  still 
referenced  by  the  ongoing  computation,  then  reclaim  all  storage  that  is 
not  so  referenced  (garbage).  Garbage  collection  Is  an  unavoidable 
overhead  of  any  system  with  no  dec laraticns , and  in  which  oata 
structures  can  grow  in  unrestricted  ways. 

une  potential  disadvantage  of  garbage  collection  is  that,  once  the 
system  runs  out  of  free  storage,  a garbage  collection  auit  occur. 


Since  a garbage  collect  causes  current  computing  activity  to  be 
suspended,  if  LISP  is  controlling  a real-time  process,  disastrous 
consequencs  can  accrue*  Such  problems  can  normally  be  avoided  t>y 
forcing  the  system  into  a premature  garbage  collect  prior  to  entering 
real-time  critical  sections  of  computation.  Alternatively,  there  is 
growing  interest  in  truly  asynchronous  (parallel)  garbage  collection 
techniques  which  could  obviate  the  problem  altogether  (see  L 0 i j kstra7i,3 
for  instance). 


3.1.11.  L1£P  as  a Se  ±.f  r£2DlaiD£  d 

LISP  interpreters  are  typically  implemented  in  assembly  language. 
After  this  basic  facility  has  been  brought  up,  most  other  supporting 
software  can  be  written  in  LISP  itself.  Typical  software  includes 

(1)  A £ 2EBi.it £ which  will  generate  (potentially  quite  gooo) 
machine  code  for  LAMBDA  expressions  (i.e.,  functions)  and 
PROOs.  Typically,  the  LISP  compiler  will  be  written  in 
interpreted  LISP,  then  used  to  compile  itself.  The  compiled 
version  is  subsequently  used  as  the  LISP  system  compiler. 

(Z)  A gg  bug  package  which  will  permit  the  tracing  and 

interactive  Sevelopment  of  functions.  Typically,  functions 
(together  with  their  calling  arguments)  can  be  traced  at 
entry  time,  and  (together  with  their  returned  values)  at 
return  time.  Most  LISPs  will  also  accommodate  the  tracing 
of  variables  (i.e.,  inform  the  user  whenever  a traced 
variable  s value  is  about  to  be  changed).  The  debugging 
potentials  of  LISP  are  essentially  unlimited  (the  INTERLISP 
system  is  the  most  advanced  to  date),  and  are  responsible 
(in  part)  for  LISP  s reputation  as  one  of  the  best 
languages  for  the  efficient  and  rapid  development  of 
complex  software.  In  particular,  there  is  no  time-consuming 
interaction  with  system  compilers,  loaders  and  linkers  to 
be  contended  with;  a program  can  be  developed  and  put  into 
production  within  the  confines  of  the  LISP  system  itself. 

(3)  An  S-expression  editgr  (or  system  editor  interface)  which 
makes  possible  TKe'convenient  editing  of  S-e xpre s si ons  and 
maintenance  of  files. 


3.2.  MlCSfiELAStiEB 

While  LISP  is  generally  accepted  as  the  standard  for  computing  in 
AI,  it  does  not  supply  the  user  with  any  a-priori  conceptions  aoout 
intelligence.  LISP  is  simply  the  blank  tablet  onto  which  the  user  must 
write  his  theory  of  intelligence  or  control.  Not  surprisingly,  this 
resulted  in  numerous  reinventions  of  the  wheel  in  areas  like  database 
organization,  problem  solving,  hypothetical  reasoning,  and  language 
understanding.  Most  reinventions  were  at  a fairly  low  level,  but 
occurred  often  enough  to  warrant  some  investigations  into  some  of  the 
undercurrents  of  AI  programming  techniques. 

MICROPLANNER  [Sussman,  winograd,  Charniak  713  is  the  outcropping 
of  some  of  these  undercurrents,  particularly  where  automatic  problem 
solvina  is  concerned.  MICROPLANNER  was  written  in  1970-71  as  a 
small-scale  implementation  of  ideas  originally  proposed  by  Hewitt  in 
1969  £Hewitt693.  The  intent  of  the  language  was  and  is  to  provide  some 
automatic  mechanisms  of  database  organization,  context,  and  heuristic 
search. 

MICROPLANNER  is  implemented  entirely  in  LISP.  Because  of  this,  its 
syntax  is  essentially  LlSP's  syntax,  and  while  in  the  MICROPLANNER 
environment*  the  user  has  full  access  to  all  of  LISP.  To  distinguish 
MICROPLANNER  (hereafter  abbreviated  MP)  functions  from  pure  LISP 
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functions,  the  convention  is  to  prefix  all  MP  functions  (there  art 
about  30  of  them)  with  "TH"  (standing,  we  presume,  for  "theorem",  a key 
notion  in  MP). 

The  most  salient  features  of  MP  are  these: 

(1)  Computation  in  MP  is  induced  by  pattern,  rather  than  oy 
calling  functions  by  their  names.  In  this  style  of 
computation  (often  called  "p  at  t er  n-d  i re  c t ed  invocation"), 
whenever  a goal  requires  solution,  a pattern  describing  the 
goal  is  posted  to  the  entire  system.  "Entire  system" 
normally  means  a large  population  of  problem-solving 

experts  with  patterns  which  advertise  each  one's  expertise. 
Whenever  a need  is  posted,  the  system  searches  through  the 
database  of  experts  looking  for  those  whose  advertised 
Patterns  match  the  need.  Each  expert  so  located  is  then 
tried  in  turn  until  one  succeeds,  or  until  all  have  failea. 

This  is  a radically  different  computing  paradigm  from  the 
standard  paradigm  of  "name  calling",  since  it  makes  for  a 
very  modular  system  where  the  requestor  needn't  know  any 
experts  by  name;  problems  are  solved  by  anonymous  experts 
in  the  population  at  targe. 

(I)  Mr  automatically  maintains  a context-sensitive  database  of 
both  factual  assertions  and  the  experts  just  mentioned.  The 
factual  database  is  a collection  of  highly  indexed 
n-tuplesj  expressed  as  LIoP  S-e xpr e ss i on s . Any  one  n-tuple 
("assertion"),  or  collection  of  n'tuples  can  oe 

" as soc i at i ve l y"  accessed  by  presenting  the  lookup  routines 
with  a pattern  containing  zero  or  more  variables.  Only 
those  facts  that  are  deemed  active  in  the  current 

"context",  regardless  of  whether  they  physically  exist  in 
the  memory,  will  be  located. 

(3)  MP  ooes  all  the  bookkeeping  required  for  depth-first, 
nonoet e rm i ni s t i c programming.  That  is,  anytime  there  is  a 
decision  of  any  sort  in  MP,  the  system  makes  a choice 
(either  arbitrarily,  or  under  the  control  of  user-specified 
heuristics),  records  the  alternatives  for  possible  future 
reference,  and  then  proceeds.  If  a failure  ever  causes  a 
"backup"  to  that  decision  point,  the  system  automatically 
discards  the  current  (failing)  choice,  selects  the  next 
alternative,  and  then  attempts  to  proceed  again.  In  tne 
backup  process,  all  computations  performed  between  the 
initial  (bad)  choice  and  the  failure  point  are  undone  (a 
record  of  all  changes  to  the  database  is  maintained),  and 
the  system  picks  up  from  the  decision  point  as  though 
nothing  had  ever  gone  wrong.  Thus,  MP  can  be  said  to 
maintain,  at  least  implicitly,  an  entire  goal  tree  (search 
tree)  for  each  problem  it  attempts  to  solve.  As  we  will 
suggest  later,  there  are  both  advantages  and  disadvantages 
to  such  automatic  control. 


These  are  the  three  main  contributions  of  MP.  In  the  following 
sections  we  highlight  and  illustrate  some  of  the  specific  features  of 
this  problem  solving  language. 


3.2.1.  The  MI CRO PLANNER  Database 

Conceptually,  the  MP  database  is  divided  into  two  segments:  facts 
and  theorems.  Theorems  are  further  classified  into  three  categories: 
"antecedent"  theorems,  "erasing"  theorems^  and  "consequent"  theorems. 
Theorems  are  discussed  in  section  3.2.2. 

Both  facts  and  theorems  are  entered  into  the  database  via  the 
function  THASSERT;  an  item  is  deleted  from  the  database  via  the 
function  THERASE.  Facts  are  f u l l y -c ons t an t LISP  n-tuples.  Thus,  to 
represent  our  screwdriver  in  MP,  we  might  augment  the  database  as 


18 


' .V 


jri 


f ol low s : 


(THASSERT  (TOOL-TYPE  S C k EW  D RI  VE  R - 1 SCREwDRIVER)) 
(THASSERT  (STYLE  S C R E W OR  I V E R-  1 PHILLIPS)) 

(THASSERT  (HEAD-SIZE  S C R EWD RI V ER -1  0.3  CM)) 


Database  lookups  and  fetches  are  accomplished  via  the  function 
THSOAL.  Therefore,  if  at  some  point  in  a MP  program,  we  required  a 
knowledge  of  SCREWDRIVER -I's  head  width,  we  could  write  a fetch  pattern 
of  the  torm: 


( THoOAL  (HEAD-SIZE  SCREWDRIVER-1  (THV  X)  (THV  Y))) 


For  our  example,  this  would  respond  with  "success"  (i.e.,  a fact  which 
matched  this  template  was  located  in  the  database,  and  it  would  produce 
the  side  effects  of  binding  the  MP  variables  X and  Y to  0.3  and  CM, 
respectively.  the  THV  form  is  used  in  MP  to  signal  references  to 
variables  (all  else  is  implicitly  constant). 

Every  fact  and  theorem  in  the  MP  database  has  a context  marking, 
whenever  a fact  or  theorem  is  THASSERTeo,  if  such  a fact  is  not  alreacy 
present  in  the  database,  it  is  created  and  then  marxed  as 
aTso  oeing  l2S''£.iiiX  present.  If  the  THASSERTed  fact  is  present 
Dhysically,  “but  marked  as  logically  qo£  present,  its  logical  status  is 
changed  to  "present".  If  the  fact  is  already  logically  and  physically 
present,  THASSERT  does  nothing,  out  reports  a "failure"  to  store  a new 
copy  of  the  fact.  ThERASE  exerts  opposite  effects  on  facts  in  the 
database:  it  causes  a fact  to  be  logically  masked,  either  by  changing 

the  fact  s logical  context  marking,  or  by  actually  physically  deleting 
the  fact  (i.e.,  if  the  fact  is  being  THERASEd  at  the  level  at  which  it 
was  2CiSiQ2iiT  THASSERTed). 

Context  markings  allow  MP  to  keep  track  of  the  history  of  the 
logical  status  of  each  fact  and  theorem.  This  enables  the  system  to 
back  up  to  prior  context  levels,  thereby  restoring  the  database  to  the 
cor resoonoi ng  prior  state.  Thus,  although  there  are  mechanisms  for 
makins  permanent  oatauase  changes  (e.g.,  after  some  segment  of  MP  cooe 
is  cunfiuent  that  what  it  has  done  is  absolutely  correct),  normally 
(except  at  the  top  level),  THASSERT's  and  THERASE 's  are  not  permanent; 
instead,  they  normally  exist  only  for  the  duration  of  some  stretch  tf 
planning  or  hypothetical  reasoning. 


3.2.2.  ai£ReELA5ibf&  ItSSfiESjis 

All  reasoning  (in  fact,  all  computation)  in  MP  is  carried  out  by 
THANTE,  THERASINto,  and  THCONSE  "theorems"  which  are  called  by  pattern 
rather  than  by  name.  The  three  types  of  theorem  . are  indistinguishable 
in  internal  form,  except  with  regard  to  the  type  of  event  to  which  each 
responds.  A THANTE  theorem  is  triggered  by  the  THASSERTion  into  the 
factual  database  of  any  pattern  which  matches  its  invocation  pattern.  A 
THERASING  theorem  is  triggered  by  the  THERASEure  from  the  database  of 
any  factual  pattern  which  matches  its  invocation  pattern.  In  the  sense 
that  these  two  classes  of  theorems  respond  spontaneously  (not  in 
response  to  any  particular  request),  they  represent  a general  interrupt 
capability.  A ThCONSE  theorem  responds  to  THGOAL  requests  whose  go*l 
patterns  match  its  invocation  pattern. 

Because  of  this  last  interaction  between  THGOAL's  and  THCONSE,  a 
THGOAL  can  amount  to  considerably  more  than  a simple  database  fetch. 
In  MP,  when  a THGOAL  is  issued,  the  system  first  attempts  to  locate  the 
desired  goal  directly  as  a fact  in  the  database.  If  this  fails,  and 
the  THGOAL  request  has  indicated  that  it  is  permissible  to  do  so,  MP 
will  begin  searching  for  THCONSE  theorems  whose  invocation  patterns 
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match  the  desired  goal.  If  any  are  found,  each  is  executed  in  turn 
until  one  reports  success  (in  which  case  the  TH60AL  is  satisfied),  or 
until  all  THCONaE  theorems  have  failec  (in  which  case  the  THcGr.L 
fails)*  It  is  in  this  manner  that  more  complex  knowledge  li.e., 
theorems,  problem  solving  techniques,  etc.)  can  be  automatically 
Brought  to  bear  on  some  goal  if  that  goal  is  not  alreaoy  explicitly 
present  in  the  factual  database. 

The  forms  of  these  three  MP  theorem  types  are: 


(THANTE  <opt i on  a l -n ame>  <variables>  < i nvocat ion-pat tern>  <bcdy>) 
(THERAS1N6  < opt i ona l-name > <variables>  < i n vo ca t i on-p a t t e rn>  <bouy>) 
(THCONSt  <op t iona l-na me>  <variac les>  < i n voc a t i on-pa t t er n > <Lody>) 


As  a brief  illustration  of  the  uses  of  each  of  these,  suppose  wt 
wish  to  implement  the  following  three  capabilities  in  MP : (a)  whenever 
a new  screwdriver  is  oefined  to  the  system,  automatically  cause  its 
name  to  be  added  to  the  master  tool  list;  (b)  whenever  a screwdriver  is 
deleted  from  the  system,  automatically  remove  its  name  from  the  master 
tool  list,  and  also  remove  all  its  accompanying  information;  (c) 
whenever,  during  some  assembly  task,  a THSOAL  of  the  form:  (SCREw-lN 
<some  scrtw>  <some  threaded  hole>)  is  announcea,  automatically  »earch 
for,  and  return  the  name  of  an  appropriate  screwdriver  for  the  task 
(basea  on  the  screw's  style  and  heao  size).  Task  (a)  will  be  irodeleo  as 
a HP  THANTE  theorem,  part  (b)  by  a THERaSIKS  theorem,  and  part  (c)  oy  o 
THCONSE  theorem  as  follows: 


(THANTt  (X)  (TOOL-TYPE  (THV  X)  SCREWDRIVER) 

(SETQ  MA  STEk-TGOL-LIST  (CONS  (THV  X)  >'ASTER-TOOL-LI  ST)  ) ) 


(THERASING  (X)  (TOOL-TYPE  (THV  X)  SCREWDRIVER) 

(THPROG  (ST  CC  ...  HS  HSU) 

(SETQ  MASTER-TOOL-LIST  (DELETE  (THV  X)  M A S T ER -T 00 L -L I S T ) ) 
(THAND  (THGGAL  (STYLE  (THV  X)  (THV  ST))) 

(THFKASE  (STYLE  (THV  X)  (THV  ST)))) 

(THAND  (ThGGAL  (COLOR-CODE  (THV  X)  (THV  CC))) 

(TnERASE  (COLOR-CODE  (THV  X)  (THV  CC)))) 

(THAND  (THGGAi.  (HEAD-SIZE  (THV  X)  (THV  HS)  (THV  HSU))) 

(ThERASE  (HEAD-SIZE  (THV  X)  (THV  HS)  (THV  HSU)))))) 


(THCONSE  (SCREW  HOLE)  (SCREW-IN  (THV  SCREW)  (THV  HOLE)) 

(THPROG  (ST  HS  HSU  DRIVER  DST  DHS  DHSU) 

(THGOA..  (STYLE  (THV  SCREW)  (THV  ST))) 

(THGGAL  (HEAD-SIZE  (THV  HOLE)  (THV  HS)  (THV  HSU))) 

(THGOAL  (TOCl-TYPE  (THV  DRIVER)  SCREWDRIVER)) 

(THAND  (THGOAL  (STYLE  (THV  DRIVER)  (THV  DST))) 

(EQUAL  (THV  DST)  (ThV  ST))) 

(THAND  (THGOAL  (HEAD-SIZE  (THV  DRIVER)  (THV  DHS)  (THV  DHSU))) 
(EQuAl  (THV  DHS)  (THV  HS))) 

(THRETURN  (THV  DRIVER)))) 


3.2.3.  Heuristic  Guidance  of  Iheorem  itEiication 

it  is  possible,  by  including  special  indicators  in  THGOAl, 
THASSERT  and  THERASt  calls,  to  influence  the  order  in  which  theorems 
are  applied,  or  in  fact  to  indicate  whether  or  not  they  should  be 
applied  at  all.  Specifically,  a THGOAL  (similar  remarks  apply  to 
THASSERT  «nd  THERASL)  with  rjg  indicators  will  fail  unless  the  requestto 


goal  can  be  satisfied  exclusively  by  oatabase  fetches  (no  theorems  bill 
be  applieo).  (This  is  the  form  we  nave  been  using  for  illustration 
purposes.)  if  there  is  an  indicator  present,  it  has  either  the  form  of 
a “filter”  or  a specific  “recommendat ion  l i st " of  theorems  (referencto 
by  name).  When  o filter  is  included  in  a THGOAL  request,  only  those 
theorems  whose  properties  pass  the  filtering  test  (theorems  can  possess 
property  lists)  will  oe  candidates  for  application.  if  the  indicator 
has  the  form  of  a specific  recommendation  list,  all  theorems  on  that 
list  will  be  applieo  first  (in  order)  before  any  other  theorems  from 
the  general  theorem  base  are  attemptea.  Both  forms  allow  the  programmer 
to  insert  limiteo  heuristic  influences.  Also,  since  one  MP  theorem  can 
create  or  modify  another  MP  theorem,  the  filter  facility  provides  a 
setting  in  which  a collection  of  theorems  themselves  can  evolve  into  a 
more  structured  configuration  on  the  oasis  of  past  experience  le.g., 
who  in  the  past  has  proven  to  ue  the  most  reliable  expert).  Althou^n 
filtering  and  recommendations  are  a step  in  the  right  direction,  as 
will  discuss  latert  CONNlVER  provides  a more  flexible  environment  in 
which  to  encode  heuristic  knowledge. 


3.2.A.  S^a  rchjng  and  Bfigkufi  in  Mf; 

Search  and  backup  in  MP  can  occur  for  two  reasons:  (1)  sent 
THCONSE  theorem  which  was  run  to  accomplish  a THGOAL  fails,  and  another 
theorem  must  oe  invoked  (restoring  the  environment  to  the  state 
which  the  first  theorem  took  over),  or  (2)  some  object  to  which  the 
system  has  committee  itself  is  discovered  to  be  inappropriate,  giving 
rise  to  the  need  of  locating  another  candidate  object  and  retrying. 
The  THGO AL-TH CON SE  mechanism  underlie  the  selection  and  backup  where 
theorems  are  concerneo,  but  object  selection  is  handled  differently, 
via  the  THPROG  MP  construction. 

In  the  previous  TKCONSE  example,  the  goal  was  to  locate  some 
screwdriver  which  satisfied  some  set  of  features  (in  that  case,  the 
correct  STYLE  and  HEAD-SIZE ) . This  was  accomplished  by  a THPROG  which 
"conjectures"  that  such  an  object,  say  X,  exists,  then  proceeds  to 
determine  whether  or  not  this  conjecture  is  true.  In  the  example  above, 
the  THPROG  searched  for  a screwdriver  of  type  and  size  which  Hatched 
the  type  .no  size  of  the  particular  screw  which  was  to  be  inserted,  for 
the  sake  of  illustration,  suppose  the  screw  was  of  type  Phillips  of 
head  size  0.3.  Then,  the  THPROG  in  the  example  above  would  have 
performed  essentially  the  same  search  as  the  followina,  more  specific, 
THPROG: 


(THPROG  (X) 

(THGOAL  (TOOL-TYPE  (THV  X)  SCREWDRIVER)) 
(THGOAL  (STYLE  (THV  X)  PHILLIPS)) 

(THGOAL  (HEAD-SIZE  (THV  X)  G.3)) 
(THRETURN  (THV  X))) 


i.e.,  introduce  an  initially  uncommitted  variable,  X,  to  represent  the 
object  being  searched  for.  First,  Obtain  a candidate  for  X ty  finding 
an  oo j ect  which  is  of  TOOL-TYPE  SCREWDRIVER  (the  first  THGOAL  does 
this).  At  that  point,  X will  be  tentatively  bouno  to  the  first  such  an 
object  found.  Continue  with  this  candidate  until  either  all  THGOAL s 
have  been  satisfied  (in  which  case,  the  candidate  is  a success),  or 
until  some  THGOAL  fails  (in  which  case,  the  system  must  back  up  and 
choose  another  candidate).  Since  some  objects  may  pass  the  first 
THGOAL,  or  even  two,  but  not  all  three,  the  system  must  automatically 
keep  track  of  what  object  it  is  currently  considering,  and  what  other 
objects  remain  to  De  tested.  This  is  the  source  of  backups  which  are 
propagateo  because  of  bad  object  selections. 

To  keep  track  of  theorem  and  object  selection  backups,  HP 
maintains  a decision  tree,  THTREE,  which  is  essentially  a record  of 
every  decision  maoe,  ano  what  to  ao  in  case  the  decision  leads  to  a 
failure.  The  strength  of  THTREE  is,  of  course,  that  it  frees  the 
programmer  from  hwving  to  worry  aoout  failures:  if  there  is  a solutior, 
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it  will  eventually  be  found  by  an  exhaustive  search.  The  fatal  weakness 
of  THTREE  is  that  it  imposes  an  oft,n  undesirable  deoth-first  ordering 
on  the  search  (i.e.,  one  subgoal  must  be  solved  in  its  entirety  Defcre 
any  other  subgoals  can  be  attacked).  This  makes  it  difficult*  if  not 
impossible*  to  fabricate  complexly  intertwined  solutions*  since 
subgoals  cannot  communicate  laterally  in  the  tree.  The  organization 
is  also  quite  awkward  in  its  backup  technique  because  of  the 
depth-first  organization  of  THTREE.  Often,  one  smoll  failure  will  Cause 
an  entire  branch  of  THTREE  to  be  undone,  when  in  fact  most  of  it  wns 
correct.  It  would  be  more  desirable  to  be  able  to  discard  only  the  bod 
part  of  the  treef  retainina  the  oarts  which  are  correct,  so  that 
wholesale  resynthesis  of  large  parts  of  the  THTREE  does  not  have  to 
occur.  Unf or t jnat e ly , this  is,  again*  very  difficult,  if  not  impossible 
to  do  in  HP.  CONNlVER  has  a better  control  structure  in  these  respects. 


2.2.5.  C£h£r  Eee  E£S£rjt  aiiys  M?  CaB4feiilti£S 

To  complete  our  description  of  MICROPLANNER,  we  include  t»o 
representatives  of  the  other  functions  available  in  this  language, 
together  with  a brief  example  of  each. 


2.2.5.  1.  ( IH££ND  <moge>  < variable  s>  < s k e > <Dody  > ) 

THFIND  provides  a way  of  finding  all  objects  in  the  system  which 
satisfy  a certain  set  of  criteria.  A THFIND  is  essentially  a THPRGC 
which  is  made  to  fail  artificially  after  each  successful  location  of  an 
object  which  satisfies  the  criteria.  <mode>  indicates  how  many  oojects 
are  to  be  located  Ce.g.,  "ALL”,  "(AT-LEAST  <c oun t >)",...)  ; <variables> 
serve  the  same  role  as  THPROG  variables;  <skel>  specifies  what  form  to 
return  as  each  object  is  found;  <body>  contains  the  THG OAL "s , etc. 
which  define  the  criteria.  THFIND  returns  either  a failure  (in  case 
<mode>  number  of  objects  could  not  be  found),  or  a list  of  <skel>'s, 
each  <skel>  corresponding  to  one  successful  object  thus  found. 


EXAMPLE:  (THFIND  ALL  (X)  ( THV  X) 

(THGOAL  (TOOl-TYPE  (THV  X)  S C P EWD R I V E R ) ) 
(THGOAL  (STYLE  (THV  X)  PHILLIPS)) 


would  return  a list  of  all  tools  which  were  Phillips  screwdrivers. 


3.2.5. 2.  (JHMESS  AGE  5yarj.ab_l.es>  < £§  t te  r n>  <bogy  > ) 

As  subgoals  art  descended  into  (i.e.  "on  the  way  down"  the  goal 
tree),  THMcSSAGE  statements  have  no  effect.  They  are  essentially 
"hooks"  which  will  intercept  failures  beneath  them  in  the  goal  tree  as 
such  failures  propagate  back  up  to  the  THMESSAGE  via  a (THFAIL 
THMESSAGE  <pattern>).  Upon  being  backed  up  to  by  a THFAIL,  any 
THME5S  AGE  whose  pattern  matches  the  THFAIL  pattern  will  take  control 
(its  <body>  will  be  executed).  Thus,  the  THMESS A&E-THFAIL  combination 
provides  a way  of  a Qii£is>3ii  Qk  possible  problems  without  actually 
checking  for  them  beforehand.  IT  all  goes  well  Deneath  the  THMESSAGt, 
it  will  never  run;  however,  if  someone  gets  into  trouble  beneath  the 
THMESSAGE  (in  some  way  the  THMESSAGE  is  prepared  for),  the  THMESSAGE 
can  correct  the  problem  and  then  cause  the  part  of  the  tree  beneath  it 
to  oe  r ea  tt  emp  ted. 


EXAMPLE:  ...  (anticipate  difficulty  in  inserting  a scren) 

(THMESSAbE  (X  Y ) ( ( THV  X)  WILL  NOT  TURN  IN  (THV  Y)) 
(THGOAl  (LUBRICATE  (THV  X)))  (attempt  a remeoy) 

(THGOAl  (SCREW-IN  (THV  X)  (THV  Y))))  (retry) 


...  (attempt  to  insert  some  sere*  in  some  hole) 

...  (report  a failure  back,  up  to  the  THMESSAGE) 

(THFAIL  THnESSAGE  ((THV  SCREw)  WILL  NOT  (URN  IN 

(THV  HOLE))) 


would  anticipate*  detect*  report*  and  correct  a problem,  then  retry. 


3.3.  CONNIVER 

The  most  recent  stage  in  the  evolution  of  the  LISP  family  of 
languages  was  the  result  of  McDermott's  and  Sussman's  development  of  a 
language  called  CONNIVER  CMcDermott,  Sussman  733.  CONNIVER  s 
development  was  principally  motivated  by  the  control  structure 
deficiencies  of  MP,  as  suggestea  in  the  earlier  discussion  of  TnTREE. 
Although  there  were  some  improvements  in  the  database  ar.d 
pattern-directed  invocation  control  (e.g.,  the  pattern  matcher  is  more 
sophisticated)*  the  most  significant  feature  of  CONNIVER  is  its.aoility 
to  maintain  numerous  computations  in  states  of  suspended  animation* 
then  to  switch  among  them,  working  or.  many  subgoals  or  alternate 
strateaies  in  unison  rather  than  one  at  a time.  In  such  an  environment, 
partial  computations  need  not  be  undone  simply  because  some  small 
aspect  of  the  problem  solving  has  gone  awry. 

CONNIVER  is  less  a programming  language  than  it  is  a collection  of 
ideas  about  control  structure.  (The  language  apparently  has  never  been 
used  for  more  than  one  or  two  significant  programming  tasks 
L Fah lman733 ) . Because  of  this,  our  discussion  will  omit  most 
references  to  syntax*  and  highlight  only  the  aspects  of  CONNlVtR's 
control  structure  which  are  unusual  or  unique  to  it. 


3.3.1.  Ftarcesj  Ay-revall  IQd  Aj|i£U 

In  a conventional  programming  language  (MP  included),  one  function 
calls  another  function  either  by  name  or  pattern  and  waits  until  the 
called  function  returns  control.  In  a conventional  lanouage*  once  a 
function  returns,  that  copy  of  it  dies;  the  function  may  be  called 
anew*  but  the  new  call  will  cause  a new  "copy"  of  the  function  to 
begin.  No  memory  of  a function  s current  status  can  be  preserved  across 
call-return  sequences.  This  type  uf  control  is  usually  carries  out 
under  the  control  of  push-down  stacks  which  record  calling  arguments 
and  return  addresses;  calling  a function  causes  stacks  to  be  pushed* 
while  returning  from  a function  causes  stacks  to  be  poppeu, 
annihilating  all  control  information. 

In  CONNIVER*  things  are  quite  a Pit  different.  To  call  a function 
in  CONNIVER  is  to  create  a so-called  "frame"  for  the  called  function, 
rather  than  to  push  information  onto  a central  stack.  A function's 
frame  will  contain  all  the  information  needed  to  characterize  the 
function  at  any  moment  (e.g.,  from  what  A-iIST  it  derives  values  for 
its  free  variables*  to  whom  it  is  to  return  when  it  has  finished, 
etc.).  There  are  two  important  features  of  a frame.  First,  it  is  a 
user-accessible  LISP  data  structure.  This  means  that  a function  may 
alter  its  own  or  another  function  s frame  in  arbitrary  ways*  causing 
free  variables  to  ue  looked  up  on  some  other  function's  A-LIST,  or 
causing  the  identity  of  the  function  to  which  control  is  to  be  returned 
to  be  altered.  Second*  because  there  is  no  central  stack  which  is 
chronologically  pushed  and  popped  at  function  entry/exit,  execution 
control  is  free  to  meander  from  one  function  to  the  next  without 
permanently  closin*  any  function.  Thus,  at  any  moment,  there  can  te 


numerous  suspended  functions  which  may  be  resumed  at  the  point  at  which 
they  last  relinquished  control*  or  in  fact*  at  an  arbitrary  labeled 
point  witnin  them. 

As  one  might  expect*  this  ability  makes  the  context  marxin. 
technique  for  items  in  the  database  more  complex  than  in  ^p.  in 
particular*  since  control  may  eventually  be  returned  to  any  suspended 
function  (the  system  in  general  has  no  way  of  knowinc  whether  or  not  it 
actually  will  be)*  every  fact  in  the  database  must  have  markincs  which 
specify  for  every  suspended  function.  F , whether  or  not  that  fact  ic 
supposed  to  oe  logically  present  while  F is  running.  To  accomplish  this 
type  of  marking*  the  MP  context  scheme  was  generalised  from  u 
stack-like  arrangement  to  a tree  of  contexts.  f-asically,  every  foct 
lives  on  some  branch  of  the  tree*  and  functions  have  access  to  limbs  of 
the  tree.  Although  there  is  considerable  overhead*  the  system  manures 
to  mask  and  unmask  facts  in  the  aatabase  in  synchrony  witn  the 
meandering  of  execution  control  from  one  function  to  the  next. 

To  distinguish  the  permanent  return  of  a function  from  the  case 
where  a function  merely  relinquishes  control*  reserving  the  option  to 
continue*  CONNIVER  oefines  two  methods  of  returning:  ADIEU  (final, 
permanent  return)  and  AU-REVOIK  (suspension).  One  very  import»nt 
application  of  the  AU-REVOIR  feature  is  in  the  (often  costly) 
generation  of  alternatives.  Rather  than  calling  a * unction  (such  as 
THFIND  in  MP)  to  generate  all  possible  candidates  before  any  detailed 
filtering  tests  ore  applied  (a  procedure  which  muy  waste  an  inordinate 
amount  ot  time  in  the  initial  collecting  phase),  in  CONNIVER  it  is 
possiole  to  call  a "generator"  function  which  will  locate  and  return 
candidates  one  at  a time*  suspending  itself  across  calls.  This  makes 
for  a more  intimate  form  of  interaction  oetween  the  generating  and 
testing  functions  than  is  possible  in  MP , and  can  lead  to  more 
efficient  searches  because  of  this  intimacy.  To  facilitate  the  use  of 
generators,  CONNIVER  has  some  rather  elaoorate  machinery  for 
maintaining  " pos s i oi  l i t ie s lists"*  including  a function,  TRY-nEXT, 
which  controls  the  extraction  of  possibilities  from  such  lists. 

Computation  in  CONNIVER  is  similar  in  most  other  reoarcs  to 
computation  in  MP.  The  counterparts  of  THANTE,  THERA SINE  and  TnCONiC 
theorems  are,  respectively.  I F - ADD  ED , IF-REMOVED  and  IF-NElDED 
"methods".  Except  for  differences  in  syntax,  and  a more  general 
pattern-directed  invocation  scheme,  these  three  functions  are  the  same 
as  the  MP  versions.  CONNIVER  counterparts  of  *p's  database  ar.o 
goal-statement  functions,  THASSERT,  THERASE  and  THGOAL  art, 
respectively,  ADD,  REMOVE  ana  FETCH. 


3.4.  E f f icieQSL*  2i  i0£  LISP  tlDau3Si£  EsEiii. 

Being  an  interpreted  language*  LISP  is  slower  than,  say,  FORTRAN, 
by  between  one  and  two  orders  ot  magnitude.  However,  cgmEilec  LIsP  c«n 
be  competitive  with  a good  FORTRAN  compiler.  «e  feel  that  CIS*  provides 
the  Best  of  both  worlds,  in  the  sense  that  the-  interpreter  provides  fer 
easy  program  development  and  debugging,  while  the  LISP  compiler  can 
transform  debugged  coae  into  p rod u c t i on - le ve l efficiency. 

MICROPLANNER  ana  CONNIVER*  on  the  other  hand,  are  inherently  le»s 
efficient*  primarily  because  of  the  control  structures  they  superimpose 
on  LISP.  The  fatal  flaw  with  MP  is  its  backup  system,  which  can  te 
extremely  slow;  compilation  will  not  typically  remedy  the  problem. 
CSRRI5FR  is  slow  for  similar  reasons;  however,  in  addition  to  data 
structures*  EE2££££££  must  also  be  garbage  collected,  and  an  elaoorate 
context  tree  must  ue  maintained.  Although  these  two  languaoes  contain 
many  noteworthy  features*  we  feel  that  neither  (as  currently 
implemented)  is  appropriate  for  production  app l i c a t i c ns . 


axk  A'  x 
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3.5.  Siangan iiaiiaD  si  the  LiQsuiflfi  Umilr 


There  are  LISP  systems  lor  the  following  machines:  PDP-1C,  P&P-11, 
UNIVAC  1106,  1103,  1110,  COC  6500,  66CD,  IEK  360,  370.  SIG^A  5,  anj 
others,  temg  a relatively  easy  language  to  implement,  we  wools 
anticipate  no  sionificant  development  problems  for  any  machine, 
including  microcomputers.  Since  LISP's  syntax  is  nearly  non-existent, 
there  is  exactly  one  oialeet.  Although  there  are  minor  differences  in 
the  semantics  of  how  functions  are  defined,  and  how  variables  values 
are  accesses,  such  "incompatibilities"  can  normally  be  ameliorated  in 
about  one  day's  worth  of  mac ro- wri ti ng.  Lecause  of  this,  LISP  can  ^e 
c ha rac t er izea  as  a language  which  is  fairly  standard  and  transportable. 
Finally,  most  LISP  systems  have  an  accompanying  compiler,  usuall. 
written  in  LISP  itself. 


1 


4 . Ssiated  LiDSliaaSS 


4.1.  AL 

AL  is  a higri-level  programming  system  for  specification  cf 
manipulatory  tasks,  developed  at  Stanford  Artificial  Intelligence 
Laooratory  LFinkel7«*3,  It  is  a SAIL-tike  language  and  incluoes  lar^e 
runtime  support  for  controlling  devices. 

Trajectory  calculation  is  a cruciat  feature  of  manipulator/ 
control.  AL  contains  a vide  range  of  primitives  to  support  efficient 
trajectory  calculations.  As  much  computation  as  possible  is  done  at 
compiie-time  ano  calculations  are  modifiec  at  run-time  only  os 
necessary. 

Besides  a dimension  less  scalar  data  type  ( i • e . , PEAL),  AL 
recognises  and  manipulates  TIME.  MASS  and  ANGLE  SCALAPs,  dimensionless 
and  typed  VECTORS,  ROT  (rotation).  FRAME  (coordinate  system),  PLAN, 
(region  separator)  ano  TRANS  (transformation)  data  types.  Proper 
composition  of  variables  of  these  types  gives  a simple  means  of 
performin3  calculations  of  any  type  of  movement. 

Also  includeJ  are  PL/1“like  ON-conoi t i ons , which  allow  monitoring 
of  the  outside  worlu,  and  concurrent  processes. 
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{ move  hand  1 cm  down  from  current 
position  along  Z-axis  ) 

I FORCc(Z)  > 3000*DYNES 

DO  TERMINATE;  { keep  in  touch  with  real  world  ) 
yellow  TO  set  DIRECTLY;  l move  the  hanc  back  to  where 

it  was  in  a straight  line  > 


4.2.  Muse 


MLISP  (meta-LISP)  is  a high-level  list-processing  language 
developed  at  Stanford  University  ts*ith703.  MLISP  programs  art 
translatec  into  LISP  programs  which  are  then  executed  or  compiled.  The 
MLISP  translator  itself  is  written  in  LISP. 

ML  IS  P is  an  attempt  to  improve  the  readability  of  LISP  programs  as 
well  as  alleviate  some  inconveniences  in  the  control  structure  of  LISP 
Ce.g.t  no  explicit  iterative  construct).  Since  run-time  errors  art 
only  detecttd  by  the  LISP  system  (when  actually  executing  the  program), 
users  frequently  find  themselves  debugging  the  translated  LISP  code. 
This  somewhat  defeats  the  purpose  of  any  high-level  language. 

All  LISP  functions  are  recognized  and  translated  in  MLISP.  but  the 
Cambridge  prefix  notation  of  LISP  has  been  replaced  by  standard  infix 
anc  prexix  function  notation.  Instead  of  (PLUS  X V)  one  may  write  X * 
Y,  ana  (F00  'A  B C)  becomes  FOOC'A,  9.  C). 

MLISr  also  p roviues  a powerful  set  of  iterative  statements  and  a 
large  number  of  "vector  operators."  Vector  operators  are  used  to  apply 
standaro  operators  in  a straightforward  manner  to  lists.  Thus.  in 
MLISP,  <1,  2,  3>  +3  <6,  5,  4>  yielos  <7,  7,  7> . +3  is  the  vector 
audition  operator  and  <A,  a . C>  is  equivalent  to  (LIST  A B C)  in  LISP. 


Given  a list  of  the  form  <obj1,  ob  j 2 » ....  ofcjn>,  this  function 
will  return  a list  of  the  form  <<obj1»  holder1>,  ....  <otjn,  holdern>> 
where  holderi  is  either  PLIERS.  VISE  or  NOTHING  accordingly  as  needed 
to  hold  the  object.  X ...X  is  an  MLISP  comment. 


EXPR  HOLD-LIST(OBJ-LIST);  ,4  EXPR  starts  a regular  func  X 

BEGIN 

NEW  S;  a local  declaration  X 

RETURN  k RETURN  is  a unary  operator  X 

FOR  NEW  GPJ  IN  OoJ-LlST 
COLLECT 

a OBJ  is  local  to  the  FOR  loop.  X 
X OBJ  will  be  bound  in  turn  X 

a to  each  element  of  OBJ-LIST.  X 
a COLLECT  indicates  that  the  X 

X result  cf  each  iteration  is  X 
X to  be  APPENDed  to  the  previous  X 
X result  and  this  whole  list  X 

X returned  as  the  result  of  X 

X the  FOR.  X 


IF  (S  GETtOBJ,  SIZE))  LEQUAL  5 
THEN 

<<0 B J . 'PLIERS>> 

EL  SE 

IF  S LEWUAL  10 
THEN 

<<0B J . 'VISE>> 

ELSE 

«0BJ.  'NuTHlNG>> 

END  ; 


T 


4.3.  P&PzZ 


POP-2  is  a conversational  language  desianeo  by  R.  M.  Burstall  ana 
K . J.  Popplestone  at  the  University  01  Edinburgh  CBurstal 171 3 • 

POP-c  features  an  Algol-like  syntax  and  draws  heavily  from  LISF. 
Integers*  reals*  LlSP-like  lists  and  atoms  (called  'names  )*  function 
constants  (lambda  expressions)*  records*  arrays*  extensible  data  types, 
and  run-time  macros  are  supported*  A unique  feature  of  the  POP-.: 
system  is  the  heavy  use  of  a system  stack*  which  the  user  may  easily 
control  to  enhance  the  efficiency  of  programs* 

A full  complement  of  l i st -ma ni pu la t i on  * numeric  an- 
storage-management  functions  are  available* 

EiiSfei Si 

Suppose  we  wish  to  oDtain  a list  of  all  machinery  not  currently 
functioning.  A useful  function  would  be* 


COMMENT 


sublist  returns  a list  of  all  elements  of  argument  list  xl 
which  satisfy  argument  predicate  p ; 


xl  p; 


{ arguments  are  xl  and  p > 

< declaration  of  local*  no  type  ) 


< just  like  LISP  > 

< no  (a)  = (car  a)  ) 


FUNCTION  sublist 
VARS  x * 

IF  nult(xl)  THEN  nit 
ELSt  hd(xl)  ->  x; 

IF  p (x  ) 

THEN  x : :s  ubl  i s t ( 1 1 ( x l) « p) 

< tl(a)  = (cdr  a)*  x::l  = (cons 
ELS  b subl 1 st ( 1 1 ( x l ) * p) 

CLOSE 

CLOSE 

END; 


l)  > 


A call  mifeht  then  look  like* 


sub  list (machine -l  ist. 

LAMBDA  m;  not ( f unc t ioning (m ) ) END); 


which  might  return, 

Cpunch-pressl  drill-press2  unitlOJ 
which  is  a POP-2  list* 


4.4.  2U5E 

wLISP  is  an  extended  version  of  iA4  (a  eL ANNE R- 1 i k e LISF 
derivative)  Cfiulifson  19733  embedded  in  the  sophisticated  INTERLISP 
system*  GL1SP  supports  a wide  variety  of  cata  types  designed  to  aio  in 
the  flexiole  handling  of  large  uata  bases.  Among  the  data  types 
supported  are  "TUPLt,"  •’BAG"  ana  "CLASS."  A TUPLE  is  essentially  a LISF 
list  that  can  be  retrieved  as sociatively  (see  below).  A BAo  is  a 
multiset*  an  unoroereo  collection  of  (possibly  duplicated)  elements, 
dags  have  been  found  to  be  useful  for  describing  certain  commutative 
associative  relations.  A CLASS  is  an  unordered  collection  of 
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non-dup  li cated  elements  (i.e.,  basically  a set)* 

Arbitrary  expressions  may  be  stored  in  the  system  data  base  ano 
manipulated  a sso ciat  ively * The  QLISP  pattern  matcher  is  used  to 
retrieve  expressions  in  a flexible  manner*  Th$  system  function  MATCHLi 
may  be  used  to  invoke  the  pattern  matcher  explicitly,  as  in: 


(hATCHQQ  (<-X  <-¥)  (A  B>> 


which  causes  X to  be  Pound  to  A and  Y to  B indicates  this  "need 
for  a binding").  The  patterns  to  MATCHGQ  may  be  arbitrarily  complex, 
as  in : 


(MATCWQfl  (A  (<-X  <-¥))  < <-X  (A  <B  C)))) 


in  which  X is  bound  to  A and  Y to  (B  C)  * 

QLISP  expressions  are  represented  uniquely  in  the  data  base, 
unlike  LISP  where  only  atoms  are  unique*  To  distinguish  between 
"identical"  expressions,  "properties"  may  be  associated  with  any 
expression  by  QPUT. 


(wPUT  (UNION  (A  B))  EUUIV  (UNION  (B  C))) 


The  above  puts  the  expression  (UNION  (B  C))  under  the  property  EQU1V 
tor  the  expression  (UNION  A B)* 

0 US P provides  facilities  for  backtracking  and  pattern-directed 
invocation  of  functions,  as  illustrated  ty  : 


(wLAMBDA  (FRIENDS  JOE  (CLASS  <-F  <-$  <-<-REST)) 
(IS  (FATHER  $S  SF)) 

BACKTRACK) 


This  function  will  find  an  occurrence  of  a CLASS  denoting  FRIENDS  of 
JOE*  F and  S will  be  bound  to  the  first  two  elements  of  the  CLASS  and 
REST  will  be  bouno  to  the  remainder  of  the  CLASS  (indicated  by  "<-<-")• 
If  S is  a father  of  F , then  the  function  succeeds.  ("S"  causes  the 
current  binding  of  its  argument  to  be  used.)  BACKTRACK  causes 
r e- invoca ti on  of  the  function  with  new  bindings  for  S,  F and  REST  until 
the  function  succeeos  or  there  are  no  untr  ied  bindings . 

The  user  may  collect  teams  of  functions  to  be  invoked  under 
desired  circumstances*  Many  QLISP  data  base  manipulation  functions  may 
have  optional  arguments  which  denote  a team  of  routines  to  be  used  to 
perform  antecedent-type  functions  (as  in  PLANNER). 

& L IS P provides  a general  context  and  generator  mechanism  similar 
to  that  of  CONNIVER.  Also  provided  is  a smooth,  readily  accessible 
interface  to  the  underlying  INTERLISP  system  which  aids  in  the 
development  and  maintenance  of  large  systems. 

Future  plans  for  QLISP  include  multiprocessing  primitives, 
semantic  criteria  for  pattern  matching  (as  opposed  to  the  current 
syntactic  information),  and  the  ability  for  the  pattern  matcher  to 
return  more  information  than  a simple  match  or  fail. 


5.  E * a mg s 


5.1.  lDl£2^y£ii2D  • 

A cotton  example  will  be  useo  to  illustrate  the  d ist ingui sh in, 
features  of  SAIL,  LISP,  MICROPLANNER  and  CONNIVER.  With  only  minor 
variations  the  program  segments  use  the  same  algorithm.  The 
p rogra m -s eg  men t s appear  out  of  context  and  are  not  meant  to  indicate 
the  most  eficient  (or  preferred)  implementation  of  the  problem  in  each 
language,  but  merely  to  illustrate  the  languages'  major  attributes. 

Problem  statement: 

Given  two  distinct  assemblies  (say  Al  and  A2)  , attempt  to  unscrew  ►,  1 
from  A2,  and  indicate  success  or  failure  accordingly.  The  "world"  of 
the  example  is  assumed  to  include: 

(1)  Two  hanos,  LEFT  and  RIGHTj  capable  of  moving,  qraspinb , twisting 
and  sensing  force  and  motion. 

(2)  A fixed  number  (possioly  zero)  of  PLIERS 

(3)  A fixed  number  (possibly  zero)  of  ViSEs 

(4)  A fixed  number  of  "assemblies" 
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For  each  PLIERS  ano  VISE,  the  data  base  contains  an  assertion  of 
the  form.  "PLIERS  (VISE)  # n is  at  location  (X,  Y,  2)  and  is  of 
capacity  t cm."  In  addition,  for  each  assembly  the  data  base  contains 
an  assertion  of  the  form,  "assembly  A is  at  location  (X,  Y,  Z)  and  is 
of  size  S cm."  As  we  shall  see,  the  languages  are  distinguished  in  part 
by  the  methods  each  uses  to  represent  such  knowledge. 

Each  example  assumes  the  existence  of  the  routines  describeo  belo. 
in  ALGOL-like  notation. 

ATTACHEb(Al  , A2)  - TRUE  if  and  only  it  the  assembly  represented  ay  Al 
(heryafter  referred  to  as  Al)  is  attached  to  the  assembly 
representeo  cy  A2  (referred  to  as  A2).  The  routine  has  no 
side  effects. 

M OVE  ( H A ND  , LOCATION)  - Moves  HAND*  (LEFT  or  RIGHT)  to  LOCATION  (but  ste 
PLANNER'S  oescription  of  MOVE). 

TWISKHAND.  DIRECTION)  - Twists  HAND  (LEFT  or  RIGHT)  in  the  given 
DIRECTION  (CLOCKWISE  or  COUNTER-CLOCKWISE).  The  DIRECTION  is 
oriented  looking  down  the  length  of  the  arm.  Except  for  SAIL, 
all  programs  assume  a routine  called  TwIST-BOTh,  which  causes 
both  hanos  to  twist  at  once. 

GRASP(HAND,  OBJECT)  - Causes  HAND  (LEFT  or  RIGHT)  to  grasp  ObJECT, 
whici  must  be  within  some  fixed  range  of  HAND  (i.e.,  the  hand 
must  MOV c to  the  OBJECT  first). 

ATTEMPT  (ObJ 1 , 0BJ2,  Al,  A 2)  - Attempts  to  do  the  actual  unscrewing  of 
assembly  Al  from  A2  using  objects  0BJ1  and  0BJ2  (which,  in  our 
examples,  are  either  ViSEs  or  PLIERs).  ATTEMPT  returns  TRUE 
if  and  only  if  the  attempt  is  successful. 


Each  program  applies  the  following  sequence  to  solve  the  proolem: 


(1)  Attempt  to  unscrew  the  assemblies  using  the  hands.  This  entails 
obtaining  the  location  of  the  assemblies,  moving  the  hands  to  their 
respective  locations,  grasping,  and  then  twisting. 


(2)  If  the  objects  are  no  longer  attached*  then  return  "success*" 

(3)  At  this  point*  it  is  assumed  that  the  hands  weren't  strong  enough. 

It  is  proposeo  to  try  two  pairs  of  PLIERS  nest.  A search  ensues 

for  a suitable  set  of  available  PLIERS  (i.e.*  targe  nough  to  hole 
the  assemblies).  If  one  set  of  PLIERS  fails.  the  search  is 
continued  for  another  set*  with  the  hope  that  the  differences  among 
PLIERS  (grip*  size*  etc.)  will  eventually  lead  to  success. 

(A)  An  attesipt  to  use  PLIERS  has  failed.  Try  to  solve  the  problem  Ly 

holding  one  of  the  assemblies  in  a VISE.  Perform  a search  for  an 

appropriate  VISE.  This  search  proceeds  in  a fashion  similar  to  that 
in  <3). 

(5)  All  attempts  have  failed.  Output  an  appropriate  message  and  return 
"failure". 


* 
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5.2. 


5.2.1.  s^bcU  Ecearsfi 


INTEGER  P KOCE DURE  B I G E NOUG H ( I TE K VA R HOLDER  , HOLDEE); 


BEGIN 


END; 


" RETURN  TRUE  IFF  OBJECT  HOLDER  IS  LARGE 
ENOuGH  TO  HOLD  OBJECT  HOLDEE  " 


INTEGER  ITEMVAR  C,  S; 

C COP  (CAPACITY  X OR  hOLDER); 
S " COP  (SIZE  X 0 R HOLDEE ) ; 

R ETuftNC  DATUM(C  ) GEG  DATLM(S)) 


INTEGER  PROCEDURE  UNS C R E W ( IT E MV AR  Al,  AZ); 

" ATTEMPT  TO  DISASSEMBLE  ASSEMBLY  Al  FROM  A2,  BY  UNSCRcWINt  " 
BEGIN 

DEFINE  RUNME  = 1; 

ITEMVAR  VI,  PL1,  PL2 » PI,  P2; 

INTEGER  FLAu; 

IF  NOT  ATTACHED(A1,  A2)  THEN  RET  URN ( 1 ) ; " DON'T  BOTHER  " 

MOVE (LEFT,  LOCATION  XOR  Al  ) ; MOV  E (R I GHT  , LOCATION  XOR  A t ) ; 

G R AS  P (L  E FT,  Al);  GRASP(RIGHT,  AZ); 

" GET  BOTh  HANDS  TWISTING  AT  ONC F " 

SPROUT (Pi,  TWIST (LEFT  , C OUNTE R ! C LOC X wl S E ) , RUNME); 

S PRO  UT ( P2 , TW  1ST (RIGHT  , COUNT E R ! CLOC KW I S E)  , RUNME); 

JOIN  (■(Pi,  P 2)  ) ; 

IF  NOT  ATTACHED(A1,  A2)  THEN  RETURN(I); 

" HANDS  NOT  STRONG  ENOUGH,  TRY  PLIERS  M 
FOREACH  PlI,  PL2  I 

ISA  XOR  PLI  EQV  PLIERS  AND  (B I GENOUGH(  PLI  , AD) 

AND  ISA  XOR  PL 2 EQV  PLIERS  AND  (PLI  NEG  PL 2 ) 

AND  (BIGEN0UGH(PL2,  A2))  AND  (ATTEMPT (PLI , PL  2 , Al , A2)) 
DO  RETURN (1  ); 

" EITHER  THtRE  mEREN'T  ANY  PLIERS  LARGE  ENOUGH, 

OR  TH  E PLIERS  WEREN'T  STRONG  ENOUGH.  TRY  A 
VISE  ON  ONE  SIDE  " 

FOREACH  VI.  PLI  I 

ISA  XOR  VI  EQV  VISE  AND  (BIGENOUGH  ( VI . AD) 

AND  ISA  XOR  PLI  EQV  PLIERS  AND  (B I G ENOUGH ( PLI  , A2)) 

AND  (ATT  EMPT  (Vi,  PL  1 , Al  , A2)> 

DO  RETURN(I); 

" ALL  ATTEMPTS  FAILED  " 


2 *i 


“ t&ssiDlatx 


In  SA iL « FALSt  = 0,  TRUE  <>  0.  B IG  EN0U6H  is  a BOOLEAN  procedure. 

C and  S are  items  whose  DATUM  is  assumed  to  be  of  INTEGER  type. 

C0P(<set>)  returns  the  first  item  of  <set>.  We  are  assuming  th.t 
there  exists  only  one  triple  of  the  form  CAPACITY  XOR  <object>  EuV 
<capacity>  for  each  <object>. 

C one  S are  necessary  because  DATUK(C0P(<set>))  is  illegal.  aAlL 
must  know  at  c omp ile -t i me  what  the  type  of  a DATUM  is.  GE*  is  a 
numeric  test  for  greater  than  or  equal. 

UNSCREW  is  a BOOLEAN  procedure  which  returns  TRUE  (non-iero)  if  it 
succeeos  in  unscrewing  the  objects* 

This  is  a macro  definition.  whenever  RUNME  is  encountered  by  the 
SAIL  compiler,  it  will  be  replaced  oy  the  constant  1 . (See  29. 
for  its  use.) 

SPROUT  is  a SAIL  function  which  causes  activation  of  its  seccno 
argument  (a  pr ocedure/f unct  ion  call)  as  a process.  The  first 
argument  is  an  item  »hose  DATUM  will  be  set  oy  SPROUT  tc  contain 
information  .bout  the  SPROUTed  process  (see  41.  for  its  use).  The 
thiro  argument  to  SPROUT  determines  the  status  of  the  current  an. 
the  created  process.  RUNME  (bit  35  set)  indicates  that  tnt 
current  and  new  processes  are  to  be  run  in  parallel  by  the  sail 
s c he  cu ler  . 

bOOLEAN  tests  in  a FOREACH  must  be  enclosed  ir.  parentheses. 

Notice  (PLl  NEW  PL 2 ) to  insure  that  two  distinct  pairs  of  pliers 
are  found. 

If  the  body  of  the  FOREACH  is  entered,  then  all  went  well  and  Me 
return  success. 

CVIS  is  a SAIL  function  which  will  return  a character  string 
'name'  associated  with  an  item.  FLAG  is  set  by  CVIS  to  indicate 
the  presence  of  an  error. 
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5.3.  LiSt 
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5.3.1.  §i«fcl£  PCfiacSB 


c 

3 

4 

5 
o 

7 

8 
9 

10 

11 

1* 

14 

15 

16 

17 

18 
19 

I? 

22 

23 

24 

25 

26 
27 
2S 

29 

30 

31 

32 

33 

34 

35 

a 

38 

39 

H 

42 

43 

44 

45 

46 

47 
46 

49 

50 

51 

52 

53 

54 

55 

1? 

50 

59 

60 
61 
62 


(OEFUN  UNSCKEw  (A1  AZ) 

? ATTEMPT  DISASSEMBLY  OF  OBJECT  A1  FROM  A2,  BY  UN  SCREWING 
(PROG  (PL  1 PL  0 VI  IN) 

(CONO  C (NOT  (ATTACHED  A1  A2>)  (RETURN  T)3) 

(MOVE  'LEFT  (GET  A1  'LOCATION)) 

(MOVE  'RIGHT  (GET  A 2 ’LOCATION)) 

(GRASP  'LEFT  A1)  (GRASP  'RIGHT  Ac) 

(TWIST-EOTH  'COUNTER-CLOCKWISE) 

(COND  [ (NOT  (ATTACHED  A1  A2)  ) (RETURN  T)3) 

? HANDS  NOT  STRONG  ENOUGH,  TRY  PLIERS 

(COND  C ( F ORE  ACH  PL1  IN  PLIERS-LIST  (BIGENOUGH  PL1  AD 

PL 2 IN  PLIERS-LIST  (AND  (NOT  (EG  PL1  PL 

(BIGENOUGH  PL2 

DO  (ATTEMPT  PL  1 PL2  A1  A2 ) ) 

(RETURN  T) 3 

? PLIERS  NOT  LARGE  ENOUGH  OR  NOT  STRONG  ENOUGH. 

? TRY  A VISE  ON  1 SIDE 

C (FOR EACH  VI  IN  VISE-LIST  (BIGENOUGH  VI  A1) 

PL1  IN  PLIERS-LIST  (BIGENOUGH  PL 1 Ac) 

DO  (ATTEMPT  Vi  PL1  A1  A2)) 

(RETURN  T ) 3 

? ALL  ATTEMPTS  FAILED 

CT  ( °R  I N 1 "CAN'T  UNSCREW  ")  (PRIM  A1) 

(PRIN1  " & ")  (PRIN1  A2)  (TERPRI) 

(RETURN  NIL)3) 


(DEFUN  BIGENOUGH  (HOLDER  HOLDEE) 

? RETURN  T IFF  OBJECT  HOLDER  IS  LARGE  EN0U6H  TO 

? hold  object  holdee 

(NOT  (LESSP  (GET  HOLDER  'CAPACITY) 

(GET  HOLDEE  'SIZE))) 


) 


(DEFSPEC  FOREACH  (LAMBDA  (OBJ1  INI  LIST1  PRED1 

OB J 2 IN2  LIST2  PRED2 
DO  TRY) 

? MIMIC  SAIL  FOREACH  IN  SIMPLE  CASE 
( PR  06  (TEMPI  TEMP2) 
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mi  1-  — •'  *' 1 * ■" 


2)) 
A2  ) ) 


62 

64 

65 

66 
67 
66 

69 

70 

71 
7c 

73 

74 

75 

76 

77 
76 
79 
SO 

31 

32 

35 
64 
85 

36 

67 

68 

89 

90 

91 

92 

93 

94 

95 

96 

97 
96 
99 

100 

101 

102 

103 


LOOPl 


L00P2 


) )) 


(SETQ  TEMPI  (EVAL  LlSTl)) 

(COND  L (NULL  TEMPI)  (RETURN  NIL)3)  ? RAN  OUT 
(SET  05  J 1 (CAR  TEMPI)) 

(SETQ  TEMPI  (CDR  TEMPI)) 

(COND  C (NOT  (EVAL  PR  EDI  ))  (GC  L00P1)3)  ? FAILED  1ST  TEST 

(SETQ  TEMP2  (EVAL  L I ST  2 ) ) 

(COND  L (NULL  TEMP2)  (GO  L00PD3) 

(SET  OB  J 2 (CAR  TEMPc  ) ) 

(SETQ  TEMP2  (CDR  T EMP2 ) ) 

(COND  C (N  OT  (EVAL  P R ED  2 ) ) (GC  LOOP2)3 

C ( E V Al  TRY)  (RETURN  T)3  ? IT  WORKED 

CT  (GO  LOOP2)3) 


(DEFMAC  FORtACH  (LAMBDA  (uBJI  INI  LIST1  PRED1 

0BJ2  INc  LIST2  PRED2 
DO  TRY) 

? MACRO  VERSION  OF  FORtACH 


(LIST  'PROG 
(LI  ST 

'LOOPl 

' (COND 
(LIST 
' (SE  TQ 
(LI  ST 
(LI  ST 

' lOOP2 

' (COND 
„ (LIST 
' (SE  TO 
(LI  ST 


'(LI  L 2 ) 

'aETQ  *L1  LIST1) 

C (NULL  Li)  (RETURN  ML)]) 
'SETQ  OB J 1 '(CAR  Li)) 

Li  (CDR  L 1 ) > 

'COND  (LIST  (LIST  'NOT  PRED1) 


'SETQ 


LIST  2) 


C (NULL  L 2 ) (GO  LOOP  1)3) 

'SETQ  08 J 2 '(CAR  L? ) ) 

Lc  (CDR  L2)) 

'COND  (LIST  (LIST  'NOT  PRED2) 
(LIST  TRY  '(RETURN  T)) 
'(T  (GO  L00P2 ) ) ) ) 


(GC  LOO  Pi  ) ) ) 


(GO  LO 0 pc ) ) 


) ) 
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5.3.2.  £yfflB£DlatZ 


2.  UN  S CR  tW  is  the  main  function.  It  returns  T if  and  only  if 
oisassemoly  -as  successful. 

13.  Unlike  SAIL*  LISP  does  not  support  concurrency.  We  thus  assume  a 
primitive  function  to  get  botn  hanas  twisting. 

IS.  FOREACH  is  an  iterative  special  form  which  mimics  a simple  SAIL 
F ORE  AC  H.  FORtACH  will  try  pairs  of  pliers  until  the  aivtn 
predicates  succeed  or  it  runs  out  of  pliers  (and  returns  NIL). 
Note  that  the  arguments  to  a special  form  need  not  be  quoted. 

15.  Check  to  insure  that  distinct  pairs  of  pliers  are  found. 

34.  PRINl  is  a LISP  function  which  loads  its  argument  into  the  stream 

output  buf  fe  r. 

35.  TERPRI  is  a LISP  function  which  dumps  the  output  buffer. 

47.  Return  T if  capacity  >-  si ze. 

55.  DEFSPEC  defines  a special  form  (sometimes  called  a FE X PR ) . A 
special  form  is  identical  to  a LISP  function  except  that  its 
arguments  are  passed  unevaluated* 

63.  EVAL  is  necessary  since  the  argument  was  passed  unevaluated. 

66.  Note  the  use  of  SET  rather  than  SETQ.  OdJI  needs  to  be  evaluated 

to  w*t  the  intenoed  atom  (SET  evaluates  its  first  argument)  SETQ 

does  not) . 

66.  Note  the  use  of  EVAL  (see  63*). 

72.  Note  the  use  of  SET  (see  66.). 

82.  This  is  an  alternative  macro  version  of  FOREACH.  It  expands  into 
a PROG  which  is  similar  in  nature  to  the  special  form  FOkEACh. 
Note  the  absence  of  SET  or  EVAL* 
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21 
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23 
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26 

29 
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31 
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( TH  CON  S E UNSCREW  (A1  A2) 

(UNSCREW  ( TH V Al>  (THV  A2  ) ) 

? ATTEMPT  DISASSEMBLY  OF  OBJECT  A1  FROM  A2  , 


EY  UNSCREWING 


1 


(THOR 

(THNuT  (ATTACHED  (THY  A1)  (THV  A2>>> 

( THA  ND 

(THGOAL  (MOVE  LEFT  (THV  A1>)  ( T HTR  F THTRUE)) 
(THGOAL  (MOVE  RIGHT  (THV  A2>>  (THTBF  THTRUE)) 
(GRASP  'LEFT  (THV  AD)  (GRASP  'RIGhT  (THV  A2D 
(TwIST-bOTH  'COUNTER-CLOCKWISE) 

(THNOT  (ATTACHED  (THV  A1)  (THV  A2))) 


? HANDS  NOT  STRONG  ENOUGH,  TRY  PLIERS 
(THPROG  (PLl  PL2 ) 

(THGOAL  (ISA  (THV  PLl)  PLIERS)  (THTBF  THTRUE)) 

(THGOAL  (BIGENOUGH  (THV  PLl)  (THV  AD)  (THNODB) 

(THUSE  BIGENOUGH)  (THTBF  TrtTRUt)) 
(ThGCAl  (ISA  (THV  PL 2 ) PLIERS)  (THTBF  THTRUE)) 

(THNOT  (EC  (THV  PLl)  (THV  P Lc ) ) ) 

(THGOAL  (BIGENOUGH  (THV  PL2)  (THV  A2))  (THNODB) 

(THUSE  EIGEN0U5H)  (THTbF  THTRUL  ) ) 
(ATTEMPT  (THV  PLl)  (THV  PL2 ) (THV  AD  (THV  A2)) 

) 

? NO  PLltRS  LARGE  ENOUGH,  OR  NO  PLIERS  STRONG  ENOUGH. 

? TRY  A VISE  ON  1 SIDE 

(THPROG  (VI  PL) 

(TnGOAu  (ISA  (THV  Vi ) VISE)  (THTBF  THTRUE)) 

(THGOAL  (BIGENOUGH  (THV  VI)  (THV  AD)  (THNCDB) 

(THUSE  BIGENOUGH)  (ThTBF  ThTRUE ) ) 
(THGOAL  (ISA  (THV  PL)  PLIERS)  (THTBF  THTRUE)) 

(THGOAL  (BIGENOUGH  (THV  PL)  (THV  A2))  (THNCDB) 

(THUSE  CIGENOUGH)  (ThTEF  ThTRUE)) 
(ATTEMPT  (THV  VI)  (THV  PL)  (THV  A1)  (ThV  AZ)) 


? NOTHING  «ORKEC,  JUST  FAIL 
(THNOT  ( TH  DO 

(PRiNI  "CAN  T UNSCREW  ")  (PRIN1  (THV  A1)) 
( PCIN 1 " ")  (PRINI  (THV  A2 ) ) (TERPRI) 

) ) 

(THFAlL  THEOREM) 


(THCONSE  dIuENOUGH  (HOLDER  HOLDEE  C S) 

(BIGENOU6H  (THV  HOLDER)  (THV  HOLDEE)) 

? SUCCtEuS  ONLY  IF  OBJtCT  HOLDER  IS  LARGE  ENOUGH  TO  HOiD 
? OBJECT  HOLDEE 

(THGOAL  (CAPACITY  (THV  HOLDER)  (THV  C))  (THTBF  THTRUE)) 
(THGOAL  (SIZE  (THV  HOLDEE)  (THV  S))  (THTBF  THTRUE)) 
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63  (1HC0SD  C(NuT  (LESSP  ( THV  C)  (THV  S))) 

64  (THSUCCEED)] 

65  C 7 (THFA1L  THE  OR EN > 3 > 

06  ) 
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5.4.2.  £fiBB£Oia£¥ 


2.  Defines  end  asserts  a consequent  theorem  with  name  UNSCREW. 

3.  This  is  the  pattern  on  which  to  invoke  this  theorem  if  neeaeo 

(e.g.,  (UNSCREW  AS  SEMBLY 1 ASSEMBLY  2 ) ) . 

7.  THOR  sequentially  executes  each  of  its  arguments  until  one 

succeeds.  and  tnen  the  THOR  succeeds.  The  THOR  is  used  here  to 
prevent  undesirea  oackup. 

?.  (THNOT  p)  is  aefinea  as  (COND  Cp  (THFAID3  CT  (THSUCC  E ED ) 3 ) . 

9.  THAND  succeeds  if  and  only  if  all  of  its  arguments  succeeo.  unlike 

THOR,  backup  may  occur  among  the  arguments  of  a THAND. 

10.  Attempt  to  move  the  left  hana  to  object  Al.  There  may  be  several 
experts  (theorems)  on  moving  hands,  PLANNER  will  try  as  many  as  it 
needs.  (THT0F  THTRUE)  is  a theorem  base  "filter"  which  is 
satisfied  by  every  theorem. 

19.  THPROG  behaves  in  a similar  manner  to  THAND  except  that  local 

variables  may  be  declared. 

20.  Attempt  to  fino  a pair  of  pliers. 

21.  See  if  the  pair  of  pliers  is  large  enough.  (THNOCb)  indicates  to 

PLANNER  not  to  Lother  searching  the  data  base.  (THUSE  <theorerr>) 
inoicates  to  try  <theorem>  first. 

24.  Make  sure  that  we  have  two  distinct  pairs  of  pliers. 

45.  T H DO  executes  its  arguments  and  then  succeeds.  nowever,  at  this 
point  we  know  that  we  have  failed,  and  THNOT  is  used  to  generate  a 
failure  from  T HD 0 . This  is  necessary  because  PRlNl  returns  its 

first  argument  as  its  result,  which  (being  non-mlL)  would  cause 
the  THOR  to  succeed. 

49.  Generate  explicit  failure  of  the  theorem. 
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( CD  £ Fu  N UNSCREW  (A  1 A 2) 

? ATTEMPT  TO  DISASSEMBLE  A1  FROM  AZ  , BT  UNSCREWING 

"AUX"  (LOCI  LOC  2 GENl  GEk2  VI  PLl  P L 2 ) 

(COnD  C (NOT  (ATTACHE  D A1  A2>)  (RETURN  T > 3 ) 

(PRESENT  '(LOCATION  !,A1  !>L0C1>> 

(PRESENT  '(LOCATION  ! , A 2 ! >L  CC  2 ) ) 

(MOVE  'LEFT  LOCI)  (MOVE  'RIGHT  LCC  2 ) 

(GRASP  'LEFT  A1)  (GRASP  'RIGHT  A2) 

( C 0 N D KNOT  (ATTACHED  A1  A 2 > ) (RETURN  T)3) 

? nANDS  NOT  STRONG  ENOUGH,  TAT  FlIERS 

(CScTw  OENl  !“ ((‘POSSIBILITIES)  ‘IGNGRF 

(‘GENERATOR  (NEXT-OLJ  'PLIERS  ' ( C? IG  t N’GUGH  % A1))))) 

: PLOOP1 

(C  S c Tw  PLl  (TRY-NEXT  GENl  '(GO  'TRY-VISE))) 

(CScTv.  s»E  N2  '"((‘P0SSIE1L  1T1  fcc  ) ‘I6N0RE 

(‘GENERATOR  (NEXT-OGJ  'PLIERS 

'(AND  (NOT  (EG  PLl  i)) 

(BIC-ENOUGH  $ A2)))))) 

: PL  OOP  2 

(CScTl  PL  2 (TRY-NEXT  GEM  '(GO  'PLOOP1))) 

(CONC  [(ATTEMPT  PLl  PL2  Al  A2)  (RtToRN  T ) 2 
[T  (GO  'PLOOP2)3) 

? NO  PLIERS  LARGE  ENOUGH,  OR  «>LIERS  NOT  STRONG 
? i.  Noli  6H . TRY  A VISE  GN  ONE  SIDE. 

• TRY-VISE 

(CSlTo  OEM  !M  ((‘POSSIBILITIES)  ‘IGNORE 

(‘GENERATOR  (NEXT-OLJ  'VISE  '(PIGEN0U6*  « Al))))) 

: VL  OOP 

(CSETl  VI  (TRY-NEXT  CEN1  '(GO  'NC-C AN-DO) ) ) 

(CS  lT»  »E  N2  ^’((‘POSSIBILITIES)  ‘IGNORE 

(‘GENERATOR  (NEXT-OSJ  PLIERS  '(PIGENOUGH  $ At))))) 

: PL  OOP  3 

(CScTl  PLl  (TRY-NEXT  GEM  '(£C  'VLOCP))) 

(COND  CCATTEMPT  VI  PLl  Al  A2 ) (RETURN  T ) 3 
CT  (GO  'PL00P3  )3  ) 


46 

? ALL 

ATTEMPTS  FAILED 

47 

46 

: nO-CA  N-D  o 

49 

(PR  INI 

"CAN'T  UNSCRtW  ’’)  (PRIM  Al) 

53 

(PR  INI 

" ••)  (PRIM  A2)  (TERPR1) 

51 

(RE  TURN 

NIL) 

fs 

) 

54 

55 

56 

57 

( CD  E FUN  BiGENOUGH  (HOLDER  HOLDEE) 

56 

59 

? RETURN  T 

IFF  OBJECT  HOLDER  IS  LARGE 

66? 

? ENOUGH  TO  HOLD  OBJECT  HOLDEE 

62 

"AUX"  (C  S> 
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63 

64 

65 

66 
67 
65 
69 
7 j 

71 

72 

73 

74 

75 

76 

77 
75 
79 

sf 

62 

63 

34 
65 

35 


(PRESENT  (CAPACITY  {.HOLDER  !>C>> 
(PRESENT  '(SIZE  {.HOLDEE  !>S)) 

(NOT  (LESSP  C S > ) 

) / 


(CDEFUN  NtXT-OBJ  (TYPE  PRcD) 

? GENERATOR  TO  RETURN  NEXT  OBJECT  OF  'TYPE' 
? BHICH  SATISFIES  ' PR  E D ' 

MAUXH  (OBJ  TEHP) 

(CS  tTC  TEKP  (FETCH  '(ISA  !>OtJ  ‘.TYPE))) 


: LOOP 


(TRY-hEXT  TEHP  (ADIEU)) 

(CONC  UCVAL  (SUBST  OBJ  'S  P R ED ) ) 
(NOTE  OBJ) 

(AU-REVOlfc )D) 

(60  'LOOP) 
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5. 5. it  tfilEgn t a r i 


2.  C D E FUN  defines  a function  to  CONNIVER. 

6«  "AUX"  <list>  oefines  local  variables* 

10*  PRESENT  is  a CONNIVER  function  which  searches  the  oats  base  for  .n 
item  which  matches  its  pattern  argument*  If  one  is  founo*  PRESENT 
sets  the  indicated  variables  (marked  with  !<  or  !>  ) «no  returns 
the  item.  !,Al  indicates  the  current  CONNIVER  value  cf  A1. 
!>L0C1  indicates  that  LOCI  is  to  be  bound  if  possible* 

IS.  SERI  is  oeina  assigned  a TRY-NEXT  possibilities  list.  !"  tells 
CONNIVER  to  do  a "skeleton  expansion"  of  the  followinq  list  (which 
is  necessary  to  CONNIVER's  internals).  The  (‘POSSIBILITIES)  arc. 
•IGNORE  are  syntatic  markers  to  TRY-NEXT  whose  function  we  can 
ignore.  (‘taENERATOR  <func-call>)  indicates  to  TRY-NEXT  to  use 
<Tunc-call>  to  generate  additional  possibilities  if  needed. 

19.  NEXT-06J  will  continue  to  generate  objects  of  type  PLIERS  which 
satisfy  the  predicate  (2nd  argument).  It  will  generate  one  PLIERS 
at  a time.  (BIGENOUGH  $ A1)  is  a skeleton  predicate  which 

NEXT-OBJ  will  use  to  screen  each  possibility.  The  current 
candidate  is  substituted  for  S before  the  predicate  is  CVALuatto 
(CONNIVER's  form  of  EVALuation). 

21.  when  GEN1  contains  no  more  possibilities*  TRY-NEXT  will  execute 
(GO  'TRY-VISE).  Unlike  LISP*  GO  evaluates  its  argument  here. 

24.  Check,  to  insure  that  two  distinct  pair.,  of  pliers  will  be  founc . 

6h.  See  10. 

66.  RETURN  is  not  necessary  since  the  value  of  a CONNIVER  function  is 
the  last  expression  evaluates 

7 2.  Define  the  generator,  NEXT-OtJ.  Note  that  NEXT-G?J  looks  like  a 
regular  function  to  CONNIVER  until  it  is  called. 

79.  FETCh  is  a CGNMVER  primitive  which  returns  a possibilities  list 
of  all  items  in  the  data  base  which  match  its  pattern  argument. 
! >0B J indicates  that  OBJ  should  be  bound  by  TRY-NEXT  to  each 
possibility  in  turn. 

SI.  TRY-NEXT  binos  OoJ  from  the  possibilities  list  TEMP  and  removes 
the  current  possibility.  If  there  is  no  current  possibility* 
(ADIEU)  is  evaluated  which  causes  termination  of  the  generator. 

22.  The  oe sired  predicate  is  CVALuated  after  substituting  the  current 
object  into  the  skeleton.  (SUBST  A B C)  is  a LISP  function  which 
returns  a list  which  is  the  result  of  substituting  A for  every 
occurrence  of  fc  in  list  C. 

21.  (NOTE  OBJ ) is  o CONNIVER  function  which  places  the  current  value 
of  OoJ  otto  the  current  possibilities  list.  . 

: 4.  (AU-REVOIR)  returns  control  from  NEXT-OBJ  out  leaves  the  generator 
in  a suspended  state.  when  TRY-NEXT  returns  control  to  NEXT-OBJ, 
execution  will  resume  at  (GO  'LOOP). 
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6.  £2Q£i*Si2QS. 

Either  SAIL  or  LISP  could  provide  an  excellent  basis  for  real-time 
Dlanning  and  execution  control  of  a large  automated  shop.  However,  each 
language  possesses  features  which  facilitate  certain  types  of 
operations.  In  particular,  SAIL  is  generically  better  at  the  low  levtl 
control  of  I/O  devices,  and  has  more  extensive  abilities  for 
interacting  with  the  operating  system  (especially  where  file 
manipulations  are  concerned).  LISP,  on  the  other  hand,  is  more  flexible 
at  the  higher  planning  levels  and  where  system  development  and 
debugging  are  concerned. 

We  envision  an  "ideal"  system  as  one  which  merges  all  tr>e 
desirable  features  of  these  two  language  classes.  Such  a merger  woulc 
incorporate  LlSP's  program  and  data  structure  format,  augmented  where 
necessary  to  accommodate  SAIL-lixe  file  operations,  and  possibly  LEAP. 
SAIL  features  would  be  implanted  in  this  environment,  and,  at  tr.e 
implementor's  discretion,  an  ALGOL-like  syntax  (such  as  MLISP)  cowlu  tt 
grafted  onto  the  front  of  the  system  to  make  it  more  tractable. 

In  audition,  such  a merger  should  take  care  to  preserve  tne 
following  desirable  features  of  SAIL  anc  LISP: 

(1)  vata  structures  should  accommodate  complex  symbolic 
information  as  well:. as  primitive  types.  As  in  LISP,  data 
structures  should  be  free  to  grow  in  unrestricted  ways,  and 
storage  declarations  should  be  optional  to  the  user. 

(c)  Program  and  data  should,  as  in  LISP,  be  in  the  same  format. 

Such  a representation  underlies  (a)  a strong  macro 
facility,  lb ) rapid  editing,  modification  ano  debugging  of 
programs,  anu  (c)  se l f -modi f y i ng  and  se If-extending 
systems.  The  last  capability,  for  example,  enables  the 
system,  given  the  description  of  a new  type  of  tool, 
automatically  to  synthesize  the  programs  for  controlling 
the  tool  from  a library  of  sud- f un c t i ons • 

(3)  Strong  1/0  ana  file  manipulation  facilities,  as  are  found 
in  SAIL,  must  be  included.  A good  ranoom-access  file  system 
is  imperative  for  even  moderately  large  databases.  The 
system  should  have  both  high  and  low  level  control  over 
input  and  output  formatting  which  provides  control  down  to 
the  bit  level  of  the  machine. 

(A)  A h igh ly-aeve  loped  interrupt  subsystem  would  be  desirable. 

With  the  merger  of  SAIL's  bit-wise  interrupt  control,  and 
LISP  s symbolic  capabilities,  such  a system  as  is  described 
in  CRieger  763  could  be  efficiently  implemented.  This  would 
serve  as  the  network  protocol  for  a large  collection  of 
highly  autonomous  processes  where  the  synthesis  and  control 
of  many  parallel  events  is  important. 

(5)  For  software  development  and  debugging,  an  interpreter 
should  exist  for  the  language.  Nevertheless,  the  language 
should  be  have  a compiler  for  proauction  usage.  LISP 
currently  satisfies  these  requirements. 

(6)  The  system  should  provide  for  a large,  context-sensitive, 

associative  database.  This  would  involve  some  new 

engineering  to  coordinate  a MP-like  database  with  an 
efficient  random-access  file  system,  t Wc 0 e rmo 1 1 75  a 3 surveys 
some  ideas  on  this  topic. 

(7)  There  shoulo  oe  some  degree  of  automatic  problem-solving 
control  which  includes  a CONNIVER-l ike  context-switching 
and  process-suspending  mechanism.  Accommodations  should  be 
made  for  SAIL-like  parallel  process  control,  and  emphasis 
should  be  placed  on  inter-process  communications  protocols. 

Most  of  the  ideas  already  exist  in  CONNIVER  and  SAIL,  but 
they  need  to  be  synthesized  into  a unified  system. 
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